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

Question

[vc4vc]

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

Всего соберется таблица объемом около 40-60 млн строк постепенно (примерно по 10 строк в секунду) . И ее потом также нужно будет обновлять или добавлять новые данные в нее.

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

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

Данные будут храниться в простом виде: строчка id, название, ссылка на сайт, дата, дата,числовые и текстовые поля (всего до 10 штук).
Сама по себе база данных очень простая по структуре, и можно хранить в 1й базе данных в 1й таблице.Никаких взаимосвязей с другими таблицами не предполагается. Или может только хранить скажем категории и их номер в отдельной таблице. А в основной писать только номер категории.
Обновляться данные будут не все сразу за раз, а постепенно и постоянно (несколько добавлений/изменений в секунду или реже).
Данные в таблице будут актуальными всего примерно до 6 месяцев, те кто старше уже будут не нужны и их можно удалить.

Основной язык написания предположительно php.
Первая часть для пользователя которая показывает информацию по параметрам, вторая часть работает постоянно и постепенно добавляет/обновляет информацию в базе данных.

Какую базу данных выбрать ? Подойдет ли MySQL для этих задач?

Comments

[xmoonlight]

Er Code, да-какой-там.... время не хватит ни на что у CPU с таким трафиком)))

[vc4vc]

Er Code, дописал курсивом

Answer 1

[Евгений Вольф]

Какую базу данных выбрать ? Подойдет ли MySQL для этих задач?

При наличии должного опыта работы с ней, навыков правильного проектирования БД и полного понимания, зачем делать "именно так" и "почему не иначе?", думаю вполне подойдёт. А вообще, обычно базы оценивают не количеством записей в 1-ой (одной) таблице, а общим объёмом данных (в гига/пета- байтах) и некоторыми другими параметрами.

- поиск - есть ли запись в базе данных с указанным названием, если есть то обновляем данные там. Т.е. перед тем как добавить запись (а их напомню - вначале будет 5-40 млн и будут постоянно возрастать) будет проверять есть она в базе данных и добавлять/обновлять данные.

Для этого есть индексы, во всех известных мне базах. Предположительно - стандартный B-tree индекс, работает он во всех базах примерно одинаково.

На базу данных будут примерно такие нагрузки:

Нагрузки у Вас будут на железо а не на базу, если оно выдержит - то с точки зрения БД - логических проблем для хранения 40млн. записей - я не вижу.

Хочу узнать какими способами можно организовать структуру хранения большой информации ?

"Большой инфомрации" или больших объёмов данных? 40млн. записей - это совершенно не обязательно большой объём. Например индекс по числовому (INT) полю для 40млн. записей будет занимать всего несколько мегабайт. Для хранения именно "большой информации" - можете взять, например, PostgreSQL, там есть готовый механизм, TOAST, предназначенный специально для этого, или спроектировать базу MySQL таким образом, что бы нужные данные лежали отдельно от всякого "информационного мусора" ("хвостов"), это позволит сократить размер отдельной таблицы на диске и как следствие - повысить скорость работы с ней.

Comments

[vc4vc]

дописал курсивом

[Евгений Вольф]

vc4vc, да, я думаю MySQL для этого вполне сгодиться, для пущей скорости - можете попробовать использовать таблицы MyISAM (или их аналоги), а так же однобайтовую кодировку, например CP-1251 для хранения данных. Про остальные подробности уже написали, думаю смысла переписывать чужие ответы нет :)

Answer 2

[ThunderCat]

Каждый день или чуть реже нужно будет обновлять данные для 5-40 млн записей,

это обязательно сделать за один заход?

- поиск - есть ли запись в базе данных с указанным названием, если есть то обновляем данные там.

какого вида название? текст, хеш, инт? Длинна? В общем случае выборка по индексу происходит ОЧЕНЬ быстро, тут больше от железа зависит чем от базы.

- поиск по базе данных с указанными параметрами (например, чтобы такой-то параметр был больше указанного значения и подобные условия)

Индексы решают, если задача простые выборки из плоской таблицы - будет быстро, кроме вариантов поиска а ля `field` like %some text%.

Хочу узнать какими способами можно организовать структуру хранения большой информации ?

читайте "нормальные формы бд".

Какую базу данных выбрать ? Подойдет ли MySQL для этих задач?

Мускуль или постгес, тут уже надо смотреть на связку железо/софт, ибо у вас задача либо сильно нестандартная, либо что-то вы неверно проектируете, у вас же "суперсекретная задача", соответственно весьма пальцетыкательный ответ.

UPD:

Данные будут храниться в простом виде: строчка id,

надеюсь, это опечатка, в смысле - id типа integer?

Или может только хранить скажем категории и их номер в отдельной таблице. А в основной писать только номер категории.

читайте про нормализацию, нет, ну правда, это ВАЖНО.
Числовые данные ВСЕГДА работают быстрее смешанных(альфанумерик) при равной длине(в "символах"), надеюсь это очевидно. Соответственно выборка where categoryid = 55 будет работать быстрее чем where category = 'somecategoryname'. В остальном - не вижу особых проблем.

Comments

[vc4vc]

дописал курсивом

Answer 3

[xmoonlight]

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

Это скраппинг сервис (возможно, поисковик или какая-то аналитика соц.сети).

Я бы думал про то, как Вы будете производить получение данных до обновления для 5-40 млн записей в день на одном сервере: это ~500 запросов в секунду только для получения данных!

Вы же не хотите всё это засунуть на один сервер?!

mysql - будет достаточно. Главное позаботиться о разбиении на таблицы при приближении количества записей в одной таблице к лимитам.

Лимиты по кол-ву строк.

The MyISAM storage engine supports 2^32 rows per table, but you can build MySQL with the --with-big-tables option to make it support up to 2^64 rows per table.

Comments

[vc4vc]

нет, обновляться будет постепенно но постоянно (несколько раз в секунду)

[xmoonlight]

vc4vc, так я и посчитал про постоянно: 40 млн на протяжении суток)

[vc4vc]

xmoonlight, в день примерно 800 тысяч строк нужно будет| обновить . Это 10 операций в секунду

[xmoonlight]

vc4vc, т.е., условия - поменялись уже, да?)))
Тогда 9,25 в секунду... да...
mysql будет более, чем достаточно...
И на обработку данных - тоже не забудьте найти CPU.

Answer 4

[⚡ Kotobotov ⚡]

использую монгу для хранения статистики по запросам в поисковиках
название -> хэшированный индекс.
в бд более 2 миллиардов записей - поиск и обновление занимает менее 1 миллисекунды.
более чем 10 раз быстрее ваших требований, при хранении в 50 раз больше данных.

Answer 5

[Вячеслав Успенский]

Выше вам все верно расписали кроме одного. Нет вообще никаких причин использовать MySQL. Имхо берите PostgreSQL и наймите хорошего DBA

Comments

[vc4vc]

А Почему MySQL не рекомендуете использовать?

[Вячеслав Успенский]

Нет на то никаких причин вообще, кроме пожалуй трудности найти ей альтернативу на рф хостингах.
Если кратко то это "не бд а хер с гвоздями". Очень глупый оптимизатор, который можно завести за угол без проблем. Нет FTS, рекурсивных запросов и вагона других клевых штук.