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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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