Хранение сериализованных объектов в MySQL и производительность - PullRequest
Новая
       1

Хранение сериализованных объектов в MySQL и производительность

3 голосов
/ 12 октября 2011

Мы хотим сохранить сериализованный объект в таблице вместе с уникальным внутренним идентификатором.Мы бы только хотели читать / писать / (редко) обновлять строки.Мы никогда не взаимодействовали бы с сериализованным полем только с ID.Мы используем InnoDB,

Во-первых;

Правильно ли хранить сериализацию как поле типа текста?

Во-вторых;

Если мыне взаимодействовать напрямую с сериализованным полем, кроме r / w, это вообще повлияет на производительность нашей базы данных?

Наконец;

Было бы лучше хранить сериализованный объект в нашей файловой системевместо этого?

Чтобы дать небольшое представление о том, почему мы храним их в первую очередь, мы получаем объект от поставщика, пользователь должен выбрать несколько вариантов и нам нужно отправить объект EXACT обратно смодифицированные (выбранные) компоненты.

Ответы [ 3 ]

6 голосов
/ 12 октября 2011

  1. Да, сохранение его в виде текстового поля (тип TEXT) является правильным, но вы также можете сохранить его в двоичном формате (тип BLOB), если вас беспокоит кодировка символов.

  2. Нет, если вы когда-либо просматривали только идентификатор, который является первичным ключом, тогда он не должен иметь слишком большого эффекта производительности.

  3. Если вы используете MySQL для хранения идентификаторов, вы также можете хранить сериализованный объект в таблице, если у вас нет огромных объемов сериализованных данных, которые могли бы занять много места на диске, но затем сохранить их в файловая система будет иметь ту же проблему.

3 голосов
/ 12 октября 2011

Это звучит как простая настройка ключа -> значения - одна таблица, два столбца, первичный ключ в первом и никаких дополнительных индексов.Если ваши объекты большие, MySQL не подходит для этого.Если они маленькие, вы, вероятно, просто в порядке.Я думаю, что что-то около 12k слишком велико.Страницы InnoDB имеют размер 16 КБ, и если каждая запись с ее служебными данными занимает более одной страницы, вы начинаете создавать беспорядок.

Файловые системы хорошо справляются с этим, если вы разбиваете объекты, используя адекватное разделение папок.,Они обычно имеют проблемы, если у вас есть миллион файлов в одном каталоге.Где этот переломный момент зависит от файловой системы, так что вам придется провести некоторые исследования.Это означает некоторый пользовательский код.

MongoDB действительно подходит для парадигмы key-> value и лучше справляется с хранением объектов, чем MySQL.

В конце, если мы говоримменее 1000000 записей и менее 10 ГБ всего, просто бросьте его на MySQL и продолжайте.Я думаю, что в тот момент, когда это имеет значение, вы все равно захотите провести эталонный тест.

3 голосов
/ 12 октября 2011

Во-первых;

Правильно ли хранить сериализацию в виде текстового поля?

Да, я предлагаю вам взять для него двоичную кодировку.Blob может быть более подходящим, то есть текст IIRC.Просто предотвратите любое кодирование, просто сохраните его в двоичном виде.

Во-вторых;

Если мы не будем напрямую взаимодействовать с сериализованным полем, кроме r / w, это повлияет на производительностьнаша база данных вообще?

Не более, как если бы это были какие-либо другие данные.

Наконец;

Было бы лучше хранить сериализованныеобъект в нашей файловой системе вместо этого?

Поскольку это в основном меньшие порции данных, я бы предпочел базу данных, так как она может обрабатывать более мелкие порции данных, чем файловая система, имеющая один файл на сериализованныйкусок.

...