Огромная БД mySQL- что изучить?

Нужно сделать работоспособную базу огромных размеров - будет содержать в себе более 240 миллионов записей в одной таблице, и в несколько раз больше в другой. Сервер есть. С Базами Данных знаком на базовом уровне.
Что посоветуете изучить для быстрого старта?
Правильно ли делать такой проект на mySQl?
  • Вопрос задан
  • 648 просмотров
Пригласить эксперта
Ответы на вопрос 5
rpsv
@rpsv
делай либо хорошо, либо никак
В основном зависит все не от размера базы, а от того для чего вам эти данные, какая у них структура и как вы их будете обрабатывать.
Для начала, нужно определиться реляционная база или нет нужна.
Потом уже выбирать СУБД в зависимости от ваших задач.
Ответ написан
kumaxim
@kumaxim
Web-программист
Первое - составь схему своей БД. Третью нормальную форму знаешь? Приведи свои данные к ней, для начала.
Затем тебе нужно определить условия порций. Ознакомиться с этим можно вот здесь Если коротко - это позволяет хранить БД на более чем одном жестком диске и добавляет скорости, когда у тебя записей в таблице очень-очень много.

Затем тебе нужно понимать, какие операции у тебя происходят наиболее часто - чтение или запись. Исходя из этого выбирай механизм хранения(MyISAM или InnoDB) и оптимизируй настройки СУБД, в т.ч. кеш.

Вообще твой вопрос очень размыт. На него сложно дать однозначный ответ сейчас. Ты пишешь про 240 млн. записей. Хорошо, может быть для тебя это много, лет 5 назад я бы тоже испугался. Ты должен понять, что количество записей мало что играет. Необходимо понимать их структуру, состав, частоту обращений, характер этих обращений, размер и т.п. Выкини из головы цифру и сосредоточься на реализации. Также решай проблемы по мере их поступления. Оптимизировать что-либо стоит тогда, когда это уже работает. Оптимизировать нужно то, что понятно, а не какие-то абстрактные циферки несуществующей еще таблиц БД
Ответ написан
@andrshpa Автор вопроса
Посматриваю в строну noSQL, в частности - Хранилища колонок, а именно Apache Cassandra.
Но совсем не уверен что это будет правильным выбором.
Смущает отсутствие возможности делать привычные выборки, и так же то, что данная СУБД рассчитана больше на постоянное добавление в неё данных чем на работу с существующими.
Я несколько в замешательстве. С одной стороны, в некоторых аспекта noSQL очень привлекателен. Но как делать на нем подобные выборки //Фильтр может быть вроде: выбрать все аккаунты с +(1) на определенных сервисах(при этом на сервисы есть доп фильтр - по hard-level и domain), + еще к этому всему надо будет прикрутить фильтр по датам, упустил из виду, но в целом сути это не меняет.
я слабо представляю. Как в принципе делать их на реляционных базах данных - понятнее.

Более подробное описание задачи(дубль из моего коммента выше):
"БД содержит в себе таблицы
accounts - в ней "столбцы" - ID(автоинкремент), email(varchar 255), password(varchar 255), login(varchar 255), и comment (TEXT). Для comment понимаю что нужно выносить в отдельную таблицу т.к. их будет
немного на общем фоне и это повысит производительность.
services - ID(автоинкремент), name (varchar 255), hard_level(tinyint), domain (varchar 255)
status - ID(автоинкремент), account_id(int 11), service_id(int 11), value(tinyint)

Как это все работает думаю понятно:
В таблицу accounts вносятся аккаунты.
В таблице services практически не меняются сервисы.
В таблице status при появлении информации вносится связка account_id - соответствующий ID аккаунта из acccounts, service_id - соответствующий ID сервиса, и значение 0/1. Для одного аккаунта может быть кол-во записей от нескольких, до полного кол-ва сервисов(160+)

Сейчас в базе есть 18млн тестовых записей в accounts, на основании которых я попробовал заполнить status. там начали получаться огромные значения ID, все лагает*. На реальном количестве аккаунтов 250млн+ - значения ID в таблице status станут просто огромными - грубо говоря что в районе 42500000000 - 12-значное число, что мне кажется соооовсем не здорово.

Так же для получения результата будет использоваться JOIN при такой архитектуре таблицы, что тоже плохо для производительности.

Фильтр может быть вроде: выбрать все аккаунты с +(1) на определенных сервисах(при этом на сервисы есть доп фильтр - по hard-level и domain), + еще к этому всему надо будет прикрутить фильтр по датам, упустил из виду, но в целом сути это не меняет.

*комп i7 3770, 8gb RAM, win7, установлен отдельно Apache и mySQL(не настраивал особо пока). сервер есть примерно такой же мощности, можно ставить любую ОС и делать что угодно. "
"
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Научитесь тестировать производительность схемы базы данных и профилировать производительность запросов к этой базе.
mysql - более, чем достаточно.
Читайте ТОЛЬКО! оф. документацию!
Ответ написан
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы