YevSam 4 окт 2021 в 18:13

Какую СУБД выбрать и почему? (Статья 2)

4 мин

11K

Oracle*SQL*NoSQL*Microsoft SQL Server*

Комментарии 15

SlyFoxMan 4 окт 2021 в 18:25

Я бы к списку популярных TSDB добавил бы еще VictoriaMetrics.

DenisOmg 4 окт 2021 в 18:44

А к графовым — DGraph

YevSam 4 окт 2021 в 19:09

Спасибо за дополнение.

Да, согласен, тоже интересная СУБД - особенно интересно было почитать реальные use cases у них на сайте.

СтОит добавить в таблицу.

YevSam 4 окт 2021 в 18:47

Спасибо за комментарий!

Почитал про VictoriaMetrics - выглядит достойно. Добавлю ее в таблицу.

korsetlr473 4 окт 2021 в 20:03

Интересно услышать ваше мнение какую базу применить как писал человек выше?

Отношение "Post - Likes"

Кол-во: десятки миллионов записей для 1 поста у популярных людей

Множество запросов: "лайкнул ли User1 Post2 ?"

YevSam 6 окт 2021 в 17:37

Приветствую!

Прошу прощения, что не ответил сразу.
Конечно сложно сказать не глядя в архитектуру решения, на сколько комплексная задача, сколько сущностей и какие между ними связи.

Если я правильно понимаю, то вводные такие:
1. Есть три сущности - Люди, Посты, Лайки.
2. Самая крупная таблица (десятки миллионов записей на 1 пост) - Лайки, в которой есть ссылка на таблицы Люди, и Посты.
3. В таблицу Лайки производятся вставки. Удалений нет, изменений нет.
4. Поддерживать транзакционность необязательно

Из этих вводных вполне подходит классическая реляционная база данных.
В качестве эксперимента, я создал минимально-возможную в AWS конфигурацию
Serverless Aurora MySQL, создал в ней три сущности с индексами и foreign keys. Заполнил таблицы примерно по 20 млн строк, и выполнил запросы - отрабатывает моментально.

При этом никакой магии с партициями или запросами, все стандартно.

Итого, я бы рекомендовал использовать все таки реляционную СУБД.

mentin 4 окт 2021 в 20:57

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

Скажем, насчет Spatial - все больше аналитики требует работы с географией, поэтому ее все добавляют понемногу. Google BigQuery пару лет назад поддержал Spatial, и стал видимо наиболее масштабируемой на текущий момент аналитической базой данных для больших пространственных данных. Сейчас то же сделал Snowflake, расширили поддержку RedShift и Athena.

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

SergeKh 4 окт 2021 в 21:46

Из поисковых баз данных люди весьма активно используют sphinx, он гораздо быстрее чем эластик, хотя и менее удобен в настройке и менее функционален. "Гораздо" это как минимум в несколько раз, а иногда и в 10. В общем круто быстрее.

Fafhrd 4 окт 2021 в 22:58

Да, Шодан хорошую работу провел, я от эластика окончательно отказался, когда реалтаймовые индексы появились. А работа с поиском через стандартный мускульный клиент это что-то.

scorpka 4 окт 2021 в 22:44

Жду статью№3, где будет объяснено что из этих трёх выбрать: оракл, постгрес, или мария дб

Fafhrd 4 окт 2021 в 22:54

из этих трех надо выбирать мсскл (нет)

hard_sign 5 окт 2021 в 10:03

То, что вы перечислили, платформы одного класса, которые решают одни и те же задачи. Поэтому выбор тут исключительно по нефункциональным требованиям – стоимость, производительность, отказоустойчивость. Если высокая интенсивность обновлений и/или высокие требования к отказоустойчивости, то Oracle или PostgreSQL. Oracle существенно дороже, но и возможности вертикального масштабирования у него гораздо больше. Плюс Oracle может конкурировать и в нише аналитических БД с такими платформами как Greenplum, Teradata, Netezza (которая puredataforanalytics), MS PDW. Если один пишет, а многие читают, то тут какой-то из клонов MySQL – мария, перкона, сам мускл...