SQL

База данных для хранения больших данных?

Обдумываю один свой интернет-сайт, суть такая,

Каждый день или чуть реже нужно будет обновлять данные для 5-40 млн записей, и эта цифра будет постоянно расти, каждый месяц примерно на 5-10% записей в таблицу будет добавляться. \

На базу данных будут примерно такие нагрузки:
- поиск - есть ли запись в базе данных с указанным названием, если есть то обновляем данные там. Т. е. перед тем как добавить запись (а их напомню - вначале будет 5-40 млн и будут постоянно возрастать) будет проверять есть она в базе данных и добавлять/обновлять данные. Функция очень нужная и массовая, поэтому не хотелось бы чтобы она выполнялась дольше 0,1 секунды.

- поиск по базе данных с указанными параметрами (например, чтобы такой-то параметр был больше указанного значения и подобные условия) и эта функция будет достаточно часто использоваться (в общем количестве раз 100 в день, и в последующем будет только увеличиваться многократно в зависимости от количества пользователей сайта). Тут такая скорость не так критична, но тоже должна быть относительно быстрая (максимум скажем можно 5-20 секунд )

Хочу узнать какими способами можно организовать структуру хранения большой информации ?
Какую базу данных выбрать? Подойдет ли MySQL для этих задач?
Ulugbek Umarov
Ulugbek Umarov
296
Если вам не нужны джойны, а только хранение и получение, то можете ради интереса попробовать MongoDB. У меня на ней сейчас крутится около 4 терабайт данных.
Она быстра (особенно когда куча оперативы на сервере) , много всего держит в буфере памяти и поиск идет очень шустро (при правильном индексировании данных). Легко расширяема (как горизонтально, так и вертикально) за счет шардинга (аналог партиционирования РСУБД) , так же есть надежные механизмы по отказоустойчивости.
Еще большой плюс в сжатии данных на диске (4 терабайта физически в дата файлах на диске занимают около 600 Гигов, при использовании 'быстрого' сжатия, второй тип сжатия, который позиционируется как более основательное, но более медленное я не тестировал, этого за глаза хватает )

В целом 50 млн записей учитывая кол-во полей если в среднем взять по 1 КБ -> 50 Гигов даты -> после сжатия (коэф сжатия на быстром режиме примерно в 8 раз) -> 6 Гигов на диске. Выйгрыш в поиске будет еще в том что операции чтения с диска самые медленные, соответственно меньше данных на диске, меньше операций чтения, т. е. надо будет читать меньше дисковых блоков с данными
Болат Байжан
Болат Байжан
795
Лучший ответ
40 миллионов записей с приростом 10% в месяц через год дадут 125М, через 5 - 12 миллиардов. Дело пахнет Терадатой и соотв. железом.
Аркадий Бойцов
Аркадий Бойцов
88 293
Ulugbek Umarov ну по эти данным наверно сильно оптимистично написал,
думаю примерно может быть до 50-80 млн записей ВСЕГО на ближайшие 5 лет.

Да, я под записью понимаю просто строчку с номер, названием, и другими доп данными
Да, MySQL (точнее, MariaDB или Percona Server - форки имеют лучший функционал, чем оригинальная MySQL) вполне потянет. Но я бы предложил присмотреться к PostgreSQL.

Кстати, операция "вставка или замена" в MySQL делается одной командой: INSERT ON DUPLICATE KEY - безо всяких поисков и проверок. Есть ещё REPLACE, но эту команду лучше не использовать.

100 млн. записей - это не такие уж и большие данные. Но более чем достаточные для того, чтобы всерьёз заняться оптимизацией структуры базы данных. Прежде всего: индексы, секционирование (partition) и репликация.

Индексы ускоряют поиск (только те запросы, которые используют эти индексы) но замедляют вставку / изменение. Индексы - всегда компромисс.

Продуманное секционирование ускоряет работу с данными, но не совместимо с внешними ключами - поддержание целостности данных перекладывается на тебя.

Репликация позволяет разнести поиск и изменение данных по разным экземплярам базы данных. Но для этого нужно несколько серверов.

P.S. О многоуровневой системе не задумывался? Когда меняющиеся данные заливаются в маленькую оперативную базу, а уже из неё постепенно переносятся в большое хранилище.
Александр Аблогин
Александр Аблогин
67 986
Сервер, как понимаю, будет свой и причём не один, с такими-то запросами
Скорость критична... Сама бы посмотрела в сторону nosql СУБД (вот какую именно из них брать - не скажу, не мониторила вопрос)

MySQL однозначно не подойдёт, как и все остальные бесплатные реляционные СУБД. Насчёт платной Oracle сомневаюсь, возможно и выдержит
Эрбол Миталов
Эрбол Миталов
63 943
Ulugbek Umarov А почему реляционные не подойдут, объясните пожалуйста ?

Похожие вопросы