Мы используем 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.Остальная часть объекта непрозрачна для базы данных.Мы можем изменить «схему», просто сохранив новые свойства в body.
Столбец added_id присутствует, поскольку InnoDB физически хранит строки данных в порядке первичного ключа.Первичный ключ AUTO_INCREMENT обеспечивает последовательную запись новых сущностей на диск после старых сущностей, что помогает обеспечить локальность чтения / записи (новые сущности читаются чаще, чем старые сущности).
Хранилища нашей базы данныхнаши данные без схемы в body. <- это тема этого вопроса. </em>
Множество других интересных деталей, таких как "попадание в" данные bodyсоздавать асинхронные материализованные представления (индексы - это просто таблицы, которые создаются в автономном режиме), но они не имеют отношения к текущему обсуждению ...
Как мы должны сериализоватьструктурированные данные (пары ключ-значение) в body?
JSON или BSON будут простыми, поскольку имена полей повторяются для каждой строки.Это дает ему преимущество в гибкости, но также и большой недостаток в эффективности использования пространства (накладные расходы на строку для имен полей в сериализованных данных).Мы пытаемся сохранить вещи в памяти, и здесь важно минимизировать как память, так и площадь сети.Чем больше записей мы сможем разместить в одном пространстве, тем быстрее будут выполняться наши запросы.Мы предпочитаем относительно длинные описательные имена полей, и сокращать их, чтобы ускорить мою базу данных, неправильно!
В конце концов, JSON / BSON не работает для наших целей, если мы не усложним и не сопоставим маленькие ключи с болееописательные ключи в драйвере приложения, который обращается к базе данных.Что заставило нас задуматься ...
Хотя наша база данных не имеет схемы, на самом деле: 1) существует не слишком много разных типов сущностей, 2) версии одного и того же вида сущностей меняются не часто,и 3) когда они меняются, обычно просто добавляют другое поле.JSON / BSON не имеют встроенной поддержки управления версиями.
Буферы протокола и Thrift гораздо сложнее, когда дело доходит до управления версиями и определениями данных.Как Thrift, так и Protocol Buffers являются отличными кандидатами для сериализации данных в базы данных, а Thrift спроектирован таким образом, что формат кодирования является расширяемым.
Protocol Buffers выглядят как отличный выбор для сериализации данных в базе данных без схемы.
CouchDB и MongoDB (две самые популярные базы данных без схем?) Используют JSON и BSON соответственно, но мы не можем найти что-нибудь об использовании чего-то более продвинутого, такого как буфер протокола, в качестве формата сериализации для храненияданные без схемы.Существуют продукты, в которых хранится версия объектов определенного языка (например, хранение объектов Externalizable в Java в сетке данных или выполнение NoSQL с MySQL в Ruby), но это проблема (попробуйте получить доступ к ним с других платформ или даже из самого MySQL,и забудьте о версиях).
Кто-нибудь хранит более совместимые буферы протокола в своей базе данных или какой-то другой расширенный формат сериализации в своей базе данных без схемы?Это вопрос о том, есть ли другие варианты, кроме прямой сериализации JSON / BSON / XML для каждой строки или сериализации объектов определенного языка.Это вообще возможно?Мы что-то упустили? извините за повествование в стиле потока сознания!