Comments 21
Жаль, что в статье ничего не сказано о главных вызовах таких систем, - FK, join и транзакции. По сути, именно эти факторы подталкивают к SQL в хайлоаде.
ну так ради джоинов все такие распределенные субд и затеваются, поэтому они все как раз распределенные джоины в первую очередь и реализуют и оптимизируют, да и транзакционность не проблема. А вот строгий FK это уже редкость, я не видал
Вопрос, какие.
Из своего опыта с распределенными аналитическими СУБД могу сказать, что там все достаточно печально. Clickhouse джойнит просто отвратительно, и это заставляет адские костыли делать на уровне препроцессинга данных, чтобы джойны избежать; Greenplum и citus, скорее всего, тоже, исходя из архитектуры и теории их работы; Druid прямо в FAQ пишет, мол, если пришли за большими джойнами таблиц фактов, то идите ищите дальше. Да, есть Vertica, которая умеет джойнить, но, даже матерые DBA по ней советуют проектировать схему так, чтобы джойны были для исключительных ситуаций.
Может, в OLTP ситуация чуть лучше (не имел особо опыта), но сильно сомневаюсь. Распределенный джойн это невороятно сложный алгоритм, требующий сети, памяти, вычислений, кеширований. Кажется, что, разработчики распределенных СУБД с SQL редко туда доходят, довольствуясь фантастическими приростами скорости на group by
Из вышеупомянутого списка в продукции не видел ничего, врать не буду. О чем-то имею представление, на уровне «архитектуры и теории их работы». Из этого представления, а также из личного опыта, например с Teradata или с тем же Spark’ом могу сказать, что реализация «распределенного» джойна как операции не намного алгоритмически сложнее «нераспределенного», если вообще сложнее, и используется примерно с той же частотой, как и в «нераспределённых» БД. Да, это может быть тяжелой операцией. Но точно так же это может быть тяжелой операцией в каком-нибудь Oracle или MS SQL.
Немного отвлекаясь от темы, я вообще позволил бы сказать, что подавляющее большинство распределённых БД реализуется очень похоже. Эта статья является хорошим примером - «Строки разбиваются при помощи хэша подмножества столбцов таблицы», «срезы реплицируются на другие узлы» - где-то это я уже видел и не один раз.
Немного отвлекаясь от темы, я вообще позволил бы сказать, что подавляющее большинство распределённых БД реализуется очень похоже.
Именно. Принципы давно известны, разница в деталях реализации: как выбрать стратегию дистрибьюции, какое сжатие взять, сортировать данные или нет, есть индексы или нет, как делиты реализовать, ну и cloud native подход. А вопрос о джоинах вообще не стоит.
Единственное, это что для OLTP это по определению не эффективно.
greenplum прекрасно джоинит, при джоине по ключу дистрибьюции. Кликхаус вообще не полноценная субд. Вертика джоинит тоже хорошо, там шустрый мерж джоин по предотсортированным таблицам. Snowflake тоже хорош в джоинах, Terradata само собой
Вообще распределенные субд для аналитики в первую очередь для джоинов и делаются!!
Имеете в виду джойн, при котором и левая и правая часть итоговой строки находятся в одном и том же сегменте?
да, это максимально быстрый джоин, иначе будет этап редистрибьюции - т.е. передачи данных между сегментами, что конечно замедляет процесс для больших таблиц
Проблема в том, что он то не сильно и нужен в аналитических колоночных базах. Условно, вместо order as o join user as u on o.user_id = u.user_id можно писать максимально широкие данные сразу, обогащая order актуальным юзером на лету. Разбухшая по столбцам таблица отлично сожмется, а лишние столбцы при чтении тоже мешать не будут. По сути, то, что апологеты кликхауса практикуют, - давайте писать в единую таблицу все действия юзера, начиная от регистрации, и заканчивая платежами и просмотрами страниц, обогащая это все максимумом инфы в момент записи, и тогда джойнить не придётся примерно никогда;)
Проблемы начинаются, когда либо условия джойнов динамические и неизвестные на момент проектирования, либо природа данных такова, что их нельзя единым способом партиционировать на момент записи. И тогда да, без редистрибуции уже никуда.
широкая витрина - это просто перенос джоинов на один шаг назад в ETL воркфлове, т.е. при создании этих широких витрин. То есть в момент записи придется джоинить, так что как я и сказал - джоины в аналитических базах нужны, без них никакую аналитику не создать.
p.s. а кликхаус - это просто быстрый кэш для витрин, а не аналитическая субд
Извиняюсь за поздний приход, но с философией join не сильно и нужен Вам можно посмотреть в сторону DynamoDB, конкретно на Single Table Design. Если Вы конечно уже не посмотрели. Лично я не фанат, но при наличии виртуально неограниченных финансовых возможностей, которые заплатят за виртуально неограниченные AWS ресурсы, почему бы и нет.
Так в том то и суть, что концепция безджойновой аналитики мне глубоко неприятна, и я не вижу в этом никакого смысла)
Как раз, наоборот, быстрый и эффективный распределенный join даёт возможность на лету строить нужные витрины, и получать результат за минуты там, где любители однотаблиц ждут месяцы, пока дата инженеры им пересоберут их мегатаблицу
новое поколение
А мужики-то и не знали.
В постгресе fdw тоже с версии 9.4 кажется есть. Citus опять же существует лет 10.
Набросали модного-молодёжного, а по факту это уже давно есть
Есть-то есть. Не работает только ничего из этого на практике (если, конечно, юзкейс хотя бы мало-мальски нагруженный; в песочнице-то все всегда ок).
Прям яростно плюсую)
Citus у знакомого на проекте был, и после длительной борьбы с пропаданием данных им сами разрабы подтвердили, мол, да, в вашем кейсе пропадание данных обусловлено принципом работы базы, и никак помочь мы вам не сможем.
Над попытками приспособить в проекте с 15ТБ оперативной базой различные fdw для постгреса я и сам свечку держал, но, увы, ничем хорошим и стабильным это не закончилось.
PS но особенно обидно было не за fdw, а за debezium. Он, если бы работал, как часы, то открывал бы прям крутые перспективы, позволяя привычно работать с базой для сервисов, требующих транзакционности, но при этом иметь стрим всех изменений в очереди сообщений.
Только вопрос как это помогает всему этому автоматически из коробки работать
Если есть какой-то инструмент для такого автоматического шардирования в Postgres с удовольствием бы изучил
The Citus node you connect to will transform the SQL queries & route the transformed queries to the correct shards.
Так Citus же. К тому же это не форк Postgres, а расширение.
Ещё были менее известные расширения pg_shard и pgDash. Но если хочется самому заморачиваться, то через fdw должно быть не сложно.
Вот-вот, меня это тоже занимает.
:)
О мужиках и о том как это давно есть - https://www.teradata.com/About-Us/Our-History
А чем это принципиально отличается от горизонтального секционирования (с помощью представлений), которое появилось, если мне память не изменяет, в MSSQLSERVER версии 6.5, т.е. лет 30 назад?
Распределенный SQL: альтернатива шардированию баз данных