Прошу прощения, что не ответил сразу. Конечно сложно сказать не глядя в архитектуру решения, на сколько комплексная задача, сколько сущностей и какие между ними связи.
Если я правильно понимаю, то вводные такие: 1. Есть три сущности - Люди, Посты, Лайки. 2. Самая крупная таблица (десятки миллионов записей на 1 пост) - Лайки, в которой есть ссылка на таблицы Люди, и Посты. 3. В таблицу Лайки производятся вставки. Удалений нет, изменений нет. 4. Поддерживать транзакционность необязательно
Из этих вводных вполне подходит классическая реляционная база данных. В качестве эксперимента, я создал минимально-возможную в AWS конфигурацию Serverless Aurora MySQL, создал в ней три сущности с индексами и foreign keys. Заполнил таблицы примерно по 20 млн строк, и выполнил запросы - отрабатывает моментально.
При этом никакой магии с партициями или запросами, все стандартно.
Итого, я бы рекомендовал использовать все таки реляционную СУБД.
NewSQL - это тоже интересный тип. К сожалению с ним я меньше всего знаком, но сколько было холиварных часов потрачено на споры с коллегами в свое время ))
Да, верно про для работы с гео-данными есть специализированный тип СУБД - Spatial, я обязательно о нем напишу в следующей статье.
По поводу выбора одной СУБД для решения разных типов задач - вы правы, так можно делать, если это оправдано, но надо понимать, что скорее всего это будет компромисс. Как правило, те СУБД, которые "заточены" на работу с определенным типом данных\активностей, работают эффективнее, чем гибридные СУБД. При этом на небольших и средних нагрузках, скорее всего никто не заметит разницы, а вот при серьезных промышленных нагрузках, high-load'е, скорее всего разница в производительности будет ощутимой.
Все верно, некоторые вендоры предоставляют несколько решений под своим брендом. Я упомянул в статье про Oracle, и конечно же Microsoft SQL так же поддерживает несколько типов. Про Cosmos DB добавлю.
Спасибо за комментарий!
Это интересная тема, готов раскрыть ее в отдельной статье.
Спасибо за комментарий!
Вопрос не тривиальный, многое зависит от конкретной задач и ограничений.
Если есть чуть больше вводных, можем обсудить.
Приветствую!
Прошу прощения, что не ответил сразу.
Конечно сложно сказать не глядя в архитектуру решения, на сколько комплексная задача, сколько сущностей и какие между ними связи.
Если я правильно понимаю, то вводные такие:
1. Есть три сущности - Люди, Посты, Лайки.
2. Самая крупная таблица (десятки миллионов записей на 1 пост) - Лайки, в которой есть ссылка на таблицы Люди, и Посты.
3. В таблицу Лайки производятся вставки. Удалений нет, изменений нет.
4. Поддерживать транзакционность необязательно
Из этих вводных вполне подходит классическая реляционная база данных.
В качестве эксперимента, я создал минимально-возможную в AWS конфигурацию
Serverless Aurora MySQL, создал в ней три сущности с индексами и foreign keys. Заполнил таблицы примерно по 20 млн строк, и выполнил запросы - отрабатывает моментально.
При этом никакой магии с партициями или запросами, все стандартно.
Итого, я бы рекомендовал использовать все таки реляционную СУБД.
Спасибо за дополнение.
Да, согласен, тоже интересная СУБД - особенно интересно было почитать реальные use cases у них на сайте.
СтОит добавить в таблицу.
Спасибо за комментарий!
Почитал про VictoriaMetrics - выглядит достойно. Добавлю ее в таблицу.
Спасибо за комментарий!
NewSQL - это тоже интересный тип. К сожалению с ним я меньше всего знаком, но сколько было холиварных часов потрачено на споры с коллегами в свое время ))
Обязательно потестирую SingleStore.
Спасибо за комментарий!
Да, верно про для работы с гео-данными есть специализированный тип СУБД - Spatial, я обязательно о нем напишу в следующей статье.
По поводу выбора одной СУБД для решения разных типов задач - вы правы, так можно делать, если это оправдано, но надо понимать, что скорее всего это будет компромисс. Как правило, те СУБД, которые "заточены" на работу с определенным типом данных\активностей, работают эффективнее, чем гибридные СУБД. При этом на небольших и средних нагрузках, скорее всего никто не заметит разницы, а вот при серьезных промышленных нагрузках, high-load'е, скорее всего разница в производительности будет ощутимой.
Во всем должен быть разумный подход. ))
Спасибо за комментарий!
Все верно, некоторые вендоры предоставляют несколько решений под своим брендом. Я упомянул в статье про Oracle, и конечно же Microsoft SQL так же поддерживает несколько типов.
Про Cosmos DB добавлю.
Выбор конкретную СУБД из множества имеющихся на рынке - хорошая идея для отдельной статьи.
Спасибо за комментарий!
Да, можно добавить DB2 в список. Был у меня опыт работы с такой СУБД - надо отметить что очень неприхотливая.
Спасибо за комментарий.
Про Druid добавлю.
Про колоночные БД - тут все зависит от конкретной СУБД.
Спасибо за комментарий. Предполагал о Teradata написать в одной из следующих статей.
Согласен, добавлю.
Согласен.
Спасибо за замечание.
BigQuery конечно будет релевантнее, ведь в BigQuery можно делать запросы из BigTable.
https://cloud.google.com/bigquery/external-data-bigtable#java