Я могу хранить много данных (<= 4 ГБ) в одном столбце таблицы. Но хорошая ли это идея?

0

Чтобы сделать короткую историю, одна часть приложения, над которым я работаю, должна хранить несколько большой объем данных в базе данных, для другой части приложения, которую нужно подобрать позже. Обычно это будет < 2000 строк, но может иногда превышать 300 000 строк. Данные должны быть временно сохранены и впоследствии могут быть удалены.

Я играю с различными идеями, и сегодня на ум приходит одна вещь. Тип данных LONGTEXT может хранить максимум 2 ^ 32 байта, что соответствует 4 ГБ. Теперь, что много материала, чтобы втиснуть в одну строку таблицы. Имейте в виду, что данные, вероятно, не превысят 60-80 МБ. Но мой вопрос: хорошо ли это сделать?

Два решения, которые я сейчас использую при использовании, выглядят примерно так:

  • Вставка всех данных в виде отдельных строк во временную таблицу, которая будет усечена после завершения.
  • Вставка всех данных в виде сериализованной строки в столбец LONGTEXT в строке, которая будет удалена после завершения.

Чисто с точки зрения производительности, было бы лучше хранить данные как потенциально > 300 000 отдельных строк или как запись в 60 МБ LONGTEXT?

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

Буду признателен за любые мысли по этому поводу.

Теги:

5 ответов

2
Лучший ответ

Сериализуя все эти данные в LONGTEXT... богохульство!!:)

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

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

И если вы правильно настроите свои таблицы, я очень сомневаюсь, что 60MiB данных, распространяемых более чем на 300 000 строк, будет менее эффективным, чем выбор 60Mi текста и анализ на интерфейсе.

В конечном счете возникает вопрос: думаете ли вы, что ваш интерфейс может анализировать текст более эффективно, чем MySQL может его получить?

Поделиться
1

Это должно быть хорошо, если вы используете механизм хранения памяти. В MySQL это означает использование механизма хранения MEMORY вместо InnoDB или MyISAM. В противном случае использование диска приведет ваше приложение к коленям.

Поделиться
0

Вы всегда можете сохранить его в базе данных в формате 300 000 строк и использовать memcached для кэширования данных, чтобы вам не пришлось повторять это снова. Обратите внимание, что memcached хранит его в памяти устройства, поэтому, если вы используете много этих данных, вы можете установить минимальный срок его действия. Но memcached значительно ускоряет время сбора данных, потому что вам не нужно делать запросы при загрузке каждой страницы.

Поделиться
0

Если вы собираетесь писать большой, временный BLOB, вы можете подумать о записи во временный файл в общей файловой системе.

Поделиться
0

Какие данные и как они будут использоваться? Вероятно, будет намного лучше хранить и обрабатывать его в памяти вашего приложения. По крайней мере, он будет намного быстрее и не будет загружать DB-движок.

Поделиться
  • 0
    Я бы сделал, если б мог. Частично проблема заключается в том, что модуль, собирающий данные, может находиться не на том же сервере. Следовательно, мне нужно найти централизованный способ хранения данных, где они могут быть доступны с любого из серверов. Боюсь, я не могу уйти от использования базы данных.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню