Страницы

Поиск по вопросам

воскресенье, 12 мая 2019 г.

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

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

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


Ответ

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

Комментариев нет:

Отправить комментарий