Когда выбирать реляционную БД, а когда не реляционную?

#mysql #база_данных #mysqli #nosql

Пишу сайт. Подразумевается большое количество записей разного размера. Подумал о
том, что при большом объёме записей БД будет долго обрабатывать запрос, поэтому надо
её раскинуть на несколько серверов. но вычитал, что реляционные БД плохо масштабируются
и для больших объемов данных используют не реляционные.



подВопрос:
Как поступить: пока не заморачиваться над этим и потом, при необходимости, перенести
данные в не реляционную БД ИЛИ выбрать реляционную/не реляционную БД ?
    

Ответы

Ответ 1

Подумал о том, что при большом объёме записей БД будет долго обрабатывать запрос


Планирование не может начинаться с "подумал", боттлнеки всегда бывают в иных местах.
Реляционки спокойно работают с миллионами записей.


  поэтому надо её раскинуть на несколько серверов. но вычитал, что реляционные БД
плохо масштабируются


Тут у меня опять претензия в ту же степь. Вы не знаете, что именно вы вычитали. Они
действительно плохо масштабируются из-за того, что (по крайней мере у большинства)
есть только одна модель master-slaves, которая упирается в мастер по скорости записи
(поправьте, если есть популярные движки с многочисленными мастерами). В любом случае
в базе данных не должно быть тяжелых подсчетов - если вы считаете количество записей
в БД, то это должно рассчитываться внутри БД и кэшироваться на уровне приложения, если
вы рассчитываете аналитику, то тут БД уже ничего считать не должна.

В общем, у меня большие сомнения, что вам нужна масштабируемая система. Что до нереляционок,
то их нельзя выбрать просто потому что "лучше масштабируются" - их только основных
типов четыре штуки под свои задачи (вряд ли вы будете использовать key-value или графовую
БД). Что до масштабирования, то есть row-column (т.е. хранение данных практически как
в SQL) Cassandra, которая шардит данные по узлам и имеет практически линейную масштабируемость,
т.е. добавление сервера в кластер из N серверов обеспечивает практически 100 * (1 /
N + 1) процентов прироста производительности. Если есть знание кассандры, то делать
проект на чем-то другом я не вижу смысла (единственная претензия - отсутствие готовых
утилит для миграций, но это, надеюсь, изменится), классические реляционки как концепция
по факту уже умерли - они, конечно, останутся, но в узком применении, и ближайшие N
лет их популярность будет снижаться.


Ответ 2

Во первых, выбор типа базы данных мало зависит от количества записей, а от архитектуры
приложения, специфики данных и многих других факторов.

Во вторых, реляционные базы данных отлично масштабируются. Например Кассандра способна
обрабатывать ~2к запросов в секунду и предоставляет горизонтальное масштабирование.
По моим наблюдениям в крупных проектах(миллионы записей в день) отдают предпочтение
как раз кассандре.

В третьих, не все NoSQL базы данных подходят для работы с большим количеством объектов.
Тот же RavenDB совсем не подходит для большого количества маленьких записей. Но если
объединить большое количество этих маленьких записей в один документ, то эта база прекрасно
справится.

В целом сама постановка вопроса говорит о том, что вы плаваете в вопросе.
Для работы с BigData не достаточно сделать правильного выбора базы данных, нужно
еще грамотно реализовать архитектуру. В противном случае у вас будут проблемы даже
при использовании самой подходящего инструмента для вашей задачи. Рекомендую почитать
литературу посвященную проектированию баз данных.


Ответ 3

Если хочешь всех удивить возьми nosql
Если хочешь блеснуть знанием старины возьми сетевую БД
Если хочешь получить благодарность с того света от бабушки Ады - возьми иерархическую БД
Ну и наконец, если хочешь написать что-нибудь стоящее возьми реляционную БД