Сложно-философский вопрос. Не будем рассматривать транзакции и какую-либо связь между таблицами, то есть не будет слова «реляционные (нет реляций между)». Рассмотрим просто таблицу. Таблица - набор строк, каждая строка - набор строго типизированных колонок. Хранит данные - построчно или поколоночно - неважно - зависит от задачи чтения. Главное, что таблица.
Утверждение: в форму таблицы впихивается очень существенное число разных данных. А которые не впихиваются - впихиваются при допиле движка таблиц специальными хаками, но остаётся внешне таблицей. Например мы хотим хранить key:string=[множество-uint64]. Возможно для какой-то задачи, оптимально будет сохранить и на диске и в памяти структуру данных вида (key_len, key, потом тупо последовательность всех uint64 отсортированных). И рядом хеш-табличку по key возможно. Но если бы мы записывали это в таблицу, у нас бы было N число строк вида (key, uint64), где N - число разных uint64, а key бы повторялся. Сходу это выглядит неоптимальным, потому что кучу раз key повторили, но умная таблица не будет хранить повторяющиеся key и получится так же оптимально, как в наивном подходе и расположит всю таблицу прямо как в примере выше - не как последовательность кортежей (SEE_PREV_VALUE, uint64), а прям как один список (uint64, uint64, …., uint64). Я ж говорю - с хаками, но таблица.
А теперь вопрос. Предположим вы бекенд-C++-тимлид в каком-то инновационном банке (которому не жалко рискнуть наняв вас, а не поставив везде Oracle) или в каких-нибудь там одноклассниках или в гугло-яндексе. Тут давайте не будем вспоминать, что в этих организациях реально используется или говорить, что все они давно закоренели и там таких опытов не ставят, а работает YDB - пытаюсь показать масштаб.
-
Предположим у вас есть C++ фреймворк, куда входит сетевой код принятия запросов (протокол-буфферс, например), какой-то движок хранения данных произвольного формата в файлах, код записи-воспроизвдеения WAL, код репликации, код статистики… И этот фреймворк позволяет за 20 минут под нужный формат данных наклепать на коленке новую «СУБД», написав буквально какой-то std::unordered_set в функции main() и «завернув» этот контейнер в данный фреймворк, выдав к нему доступ из сети и сериализацию/десериализацию на диск целиком и запись в WAL и т.п. То есть, к вам приходят люди, которые хотят хранить key=value, вы оформляете им новую «СУБД» с 2 методами - set и get и катите на прод, все юзают, все счастливы. Приходят другие люди, хотят по 64-битному числу хранить множество из миллиона других 64-битных чисел и искать в нём. Вы тоже быстро фигачите какую-то структуру данных на готовых контейнерах или даже достаёте из закромов какую-то свою супероптимальную, заврорачиваете в фреймворк, куяк-куяк и в продакшен. Не нужна какая-то СУБД - выкинули, не жалко, кода было мало.
-
И у вас есть второй вариант: сделать один хороший табличный «движок». Все эти клиенты получают всегда одно и то же представление, один и тот же интерфейс (возможно даже SQL). В особо упоротых сценариях вы дорабатываете этот движок под их формат данных (доработка повышает эффективность использования памяти/диска данной таблицей) и эта доработка оформляется просто в отдельный типа индекса или в некое хитрое слово, указываемое на этапе CREATE TABLE.
По какому пути вы бы двигались и ПОЧЕМУ?
-
Кажется достаточно симпатичным путём, потому что хотя каждая новая «СУБД» - снова какой-то велосипед, но трудозатраты смешны - описать центральную структуру данных, остальное готово. Более того, у сторонников супер-оптимизаций тут все козыри: мол вы в «табличном движке общего назначения» никогда не задрочитесь так, как можем мы, зная конкретную структуру данных пользователя. Что, кстати, спорно - не факт, что задрачивальщики решают какую-то реальную проблему.
-
Выглядит тоже круто, поскольку многие моменты унифицируются. Тайм Ту Маркет ещё ниже - не надо даже ждать пока под твою структуру данных разраб почешется и напишет новый (хоть и крошечный) код, ты можешь уже сейчас CREATE TABLE и в 95% случаев тебе хватит. Не хватит - тогда и придёшь ныть-оптимизировать. Универсальные моменты: способы доступа, способы анализа, язык общения между командами (все говорят про таблицы, а не каждый про свою абстрактную опердень, выраженную в каждый раз новом C++ коде), способы конвертации данных (переливка между таблицами - это понятнее, чем писать конвертеры данных между одним форматом (1) и другим форматом (1) и т.п., проще дорабатывать всякие автоматические решардинги или переливаторы данных - один раз сделали для таблиц и работает у всех, не надо каждый раз думать как оригинальный формат данных (1) обрабатывать. В конце-концов, можно сделать DROP COLUMN, что в случае (1) оборачивается жестью и конвертацией старых данных).
Спасибо.
