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

Question

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

Я обдумывал разные идеи, и сегодня мне в голову пришла одна вещь.А 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

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