Сериализация с буферами протокола в базе данных без схемы

Мы используем MySQL для хранения данных без схемы (см .: Использование реляционной базы данных для данных без схемы для решения, вдохновленного тем, как FriendFeed использует MySQL для хранения данных без схемы).

Одна большая таблица содержит все сущности для нашего приложения:

CREATE TABLE entities (
  added_id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY
, id BINARY(16) NOT NULL
, body MEDIUMBLOB
, UNIQUE KEY (id)
) ENGINE=InnoDB ;

Несколько деталей:

• Единственное обязательное свойство сохраненных сущностей - это id , 16-байтовый UUID. Остальная часть объекта непрозрачна для базы данных. Мы можем изменить «схему», просто сохранив новые свойства в теле .

• Столбец added_id присутствует, потому что InnoDB физически хранит строки данных в порядке первичного ключа. Первичный ключ AUTO_INCREMENT гарантирует, что новые сущности записываются на диск последовательно после старых сущностей, что помогает для локальности чтения / записи (новые сущности читаются чаще, чем старые сущности).

• Наша база данных хранит наши данные без схемы в теле .

• Множество других интересных деталей, таких как «проникновение» в данные тела для построения асинхронных материализованных представлений (индексы - это просто таблицы, которые создаются в автономном режиме) ), но они не имеют отношения к текущему обсуждению ...

Как мы должны сериализовать структурированные данные (пары ключ-значение) в теле ?

JSON или BSON будут просто, так как имена полей повторяются для каждой строки. Это дает ему преимущество в гибкости, но также и большой недостаток в эффективности использования пространства (накладные расходы на строку для имен полей в сериализованных данных). Мы пытаемся сохранить вещи в памяти, и здесь важно минимизировать объем памяти и сети. Чем больше записей мы поместим в одном пространстве, тем быстрее будут выполняться наши запросы. Мы предпочитаем относительно длинные описательные имена полей, и сокращать их, чтобы моя база данных работала быстрее, неправильно!

В конце концов, JSON / BSON не подходит для наших целей, если мы не сделаем более сложными и не сопоставим маленькие ключи с более описательными ключами в драйвер приложения, который обращается к базе данных. Что заставило нас задуматься ...

Хотя наша база данных не имеет схемы, на самом деле: 1) не так много разных типов сущностей, 2) версии одного и того же типа объекта меняются не часто, и 3) когда они меняются, обычно просто добавляется еще одно поле. JSON / BSON не имеют встроенной поддержки управления версиями.

Буферы протоколов и экономичность намного сложнее, когда дело доходит до управления версиями и изменений определения данных. Как Thrift, так и Protocol Buffers являются отличными кандидатами для сериализации данных в базы данных, а Thrift спроектирован таким образом, что формат кодирования является расширяемым.

Протоколные буферы выглядят отличным выбором для сериализации данных в базе данных без схемы.

CouchDB и MongoDB (две самые популярные базы данных без схемы?) используют JSON и BSON соответственно, но мы не можем найти ничего об использовании чего-то более продвинутого, например протокольных буферов, в качестве формата сериализации для хранения данных без схемы. Существуют продукты, которые хранят версию объектов на конкретном языке (например, хранят внешние объекты Java в сетке данных или выполняют NoSQL с MySQL в Ruby), но это проблема (попробуйте получить к ним доступ с других платформ или даже из самого MySQL, и забудьте о версиях).

Хранит ли кто-нибудь более функционально совместимые буферы протокола в своей базе данных или какой-либо другой расширенный формат сериализации в своей базе данных без схемы? Это вопрос о том, есть ли другие варианты, кроме простой сериализации JSON / BSON / XML для каждой строки или сериализации объектов определенного языка. Это вообще возможно? Мы что-то упускаем? извините за повествование в стиле потока сознания!