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

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

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

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

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

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

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

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


mysql database-optimization
person vonconrad    schedule 19.01.2010    source источник

Ответы (5)


arrow_upward
2
arrow_downward

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

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

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

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

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

person Atli    schedule 19.01.2010

arrow_upward
1
arrow_downward

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

person Nathan Osman    schedule 19.01.2010

arrow_upward
0
arrow_downward

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

person user224564    schedule 19.01.2010
comment
Я бы сделал, если б мог. Часть проблемы заключается в том, что модуль, собирающий данные, может находиться на другом сервере. Следовательно, мне нужно найти централизованный способ хранения данных, чтобы к ним можно было получить доступ с любого из серверов. Боюсь, я не могу отказаться от использования базы данных. - person vonconrad; 19.01.2010

arrow_upward
0
arrow_downward

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

person Tom Schlick    schedule 19.01.2010

arrow_upward
0
arrow_downward

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

person jewel    schedule 19.01.2010