Щас не будет речи про mysql, postgres и т.п. B про какие-либо реляции не будет - то есть, отношения между таблицами не волнуют. Не волнуют и транзакции.
Вот предположим у вас есть хранилка key=value. Казалось бы, в такую хранилку можно упихать примерно всё и выразить через кучу key-value любые данные и схемы и я даже знаю как на двух redis в разных кусках планеты бабки между клиентами атомарно переводить без блокчейна (CAS только прикрутить к key-value хранилке, но это примитивно делается). Это всё не ново и понятно.
А теперь предположим, что у вас есть хранилка табличек. В ней можно:
- Создать табличку со статически типизированной строгой схемой, т.е. задать набор колонок с фиксированными типами (string, int, float и т.п.).
- Добавлять/удалять колонки.
- Апгрейдить типы (sting на int поменять и хранилка сама скастит все числа из строк в инты, например).
- Хранить широкие строки (с кучей колонок), а выбирать только нужные.
- Замутить нижний слой хранения колоночный, тогда выбор отдельных колонок будет оптимизирован, а полная строка выбираться медленнее ну и пофиг.
Хотелось бы получить некий формальный список возможностей, которые даёт такой табличный вид.
Про реляции, джойны, транзакции мы тут не говорим, они сами по себе к таблицам никакого отношения не имеют и тут не интересны. SQL тоже ни при чём, в таблицу вы можете ходить по самодельному бинарному протоколу любой степени жопности, так же как и в key-value хранилку ходить через SQL (select from A value where key = K).
Например:
- Можно добиться компактности, если числа больше 999 хранить в инте, а не в строке.
- Статической типизацией колонок можно несколько ограничивать разнообразие бреда.
- Ненужные колонки можно целиком выкинуть (за разную цену в row и column движках хранения конечно, но можно) или добавить новые. Хотя в key-value можно тоже перестать пейсать какое-то поле в json или начать его пейсать, подготовив код к факту наличия этого поля.
- Великая мудрость о том, что хранение json-ов - признак дебилов, поскольку в итоге набор и типы полей в объектах достаточно фиксированы и если вы схему не зафиксировали в хранилке, то вы чёрт обоссаный наверное, который вечно живёт на временном решении - всё ещё продолжает выполняться.
- Если создать таблицу (key : string, value : string), то можно этим частным случаем таблицы поглотить всю предметную область key-value сразу целиком. Работать будет за то же время. Физически хранить это в памяти или на диске можно в итоге точно так же. Это позволит унифицировать доступ к key-value и к другого типа данным через одну хрень.
- Если в одной и той же key-value хранилке два разных отдела пытаются хранить свою инфу, то им придётся отделяться друг от друга некими «префиксами» у ключей: ключ «sobaka» у разных отделов будет выглядеть так: department1.sobaka=123, department2.sobaka=551, в итоге всё хранилище засрано этими префиксами, хотя решение тупое и надо просто поднять два разных редиса под такое, но всё-таки. А в случае табличек это просто две разные таблички, которые лежат компактнее, т.к. не надо хранить префиксы в каждой записи. Да, можно в случае key-value сжать рядом лежащие ключи по префиксам.
- Можно пилить разные интересные индексы: например по какой-то десятой int-колонке создать индекс, который упорядочивает все записи по ней и потом быстрее выбирать. А в случае key-value это надо будет те же данные налить в нужном порядке в другое хранилище и потом ещё следить за согласованностью двух.
В общем, хочется подобной фигни почитать. Чисто на уровне системы хранения, без отсылок к каким-то там продуктам уровня postgres. И это не тред о том, что мне взять - redis или postgres, речь о фундаментальных различиях в возможностях key-value и табличек.
Документ-ориентированную хрень не рассматриваю, это какой-то лютый треш и содомия, да - люди пытались улучшить key-value для рукожопов, не осиливших постгрес.
