@vc4vc

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

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

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

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

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

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

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

Какую базу данных выбрать ? Подойдет ли MySQL для этих задач?
  • Вопрос задан
  • 2494 просмотра
Пригласить эксперта
Ответы на вопрос 5
Wolfnsex
@Wolfnsex
Если не хочешь быть первым - не вставай в очередь!
Какую базу данных выбрать ? Подойдет ли MySQL для этих задач?
При наличии должного опыта работы с ней, навыков правильного проектирования БД и полного понимания, зачем делать "именно так" и "почему не иначе?", думаю вполне подойдёт. А вообще, обычно базы оценивают не количеством записей в 1-ой (одной) таблице, а общим объёмом данных (в гига/пета- байтах) и некоторыми другими параметрами.

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

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

Хочу узнать какими способами можно организовать структуру хранения большой информации ?
"Большой инфомрации" или больших объёмов данных? 40млн. записей - это совершенно не обязательно большой объём. Например индекс по числовому (INT) полю для 40млн. записей будет занимать всего несколько мегабайт. Для хранения именно "большой информации" - можете взять, например, PostgreSQL, там есть готовый механизм, TOAST, предназначенный специально для этого, или спроектировать базу MySQL таким образом, что бы нужные данные лежали отдельно от всякого "информационного мусора" ("хвостов"), это позволит сократить размер отдельной таблицы на диске и как следствие - повысить скорость работы с ней.
Ответ написан
ThunderCat
@ThunderCat
{PHP, MySql, HTML, JS, CSS} developer
Каждый день или чуть реже нужно будет обновлять данные для 5-40 млн записей,
это обязательно сделать за один заход?
- поиск - есть ли запись в базе данных с указанным названием, если есть то обновляем данные там.
какого вида название? текст, хеш, инт? Длинна? В общем случае выборка по индексу происходит ОЧЕНЬ быстро, тут больше от железа зависит чем от базы.
- поиск по базе данных с указанными параметрами (например, чтобы такой-то параметр был больше указанного значения и подобные условия)
Индексы решают, если задача простые выборки из плоской таблицы - будет быстро, кроме вариантов поиска а ля `field` like %some text%.
Хочу узнать какими способами можно организовать структуру хранения большой информации ?
читайте "нормальные формы бд".
Какую базу данных выбрать ? Подойдет ли MySQL для этих задач?
Мускуль или постгес, тут уже надо смотреть на связку железо/софт, ибо у вас задача либо сильно нестандартная, либо что-то вы неверно проектируете, у вас же "суперсекретная задача", соответственно весьма пальцетыкательный ответ.

UPD:
Данные будут храниться в простом виде: строчка id,
надеюсь, это опечатка, в смысле - id типа integer?
Или может только хранить скажем категории и их номер в отдельной таблице. А в основной писать только номер категории.
читайте про нормализацию, нет, ну правда, это ВАЖНО.
Числовые данные ВСЕГДА работают быстрее смешанных(альфанумерик) при равной длине(в "символах"), надеюсь это очевидно. Соответственно выборка where categoryid = 55 будет работать быстрее чем where category = 'somecategoryname'. В остальном - не вижу особых проблем.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Каждый день или чуть реже нужно будет обновлять данные для 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.
Ответ написан
angrySCV
@angrySCV
machine learning, programming, startuping
использую монгу для хранения статистики по запросам в поисковиках
название -> хэшированный индекс.
в бд более 2 миллиардов записей - поиск и обновление занимает менее 1 миллисекунды.
более чем 10 раз быстрее ваших требований, при хранении в 50 раз больше данных.
Ответ написан
Комментировать
Kwisatz
@Kwisatz
Больше web-приложений, хороших и разных
Выше вам все верно расписали кроме одного. Нет вообще никаких причин использовать MySQL. Имхо берите PostgreSQL и наймите хорошего DBA
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

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