Что лучше - хранить неупакованные данные в 10 раз больше или зипать/раззипать при чтении-записи, но объем в базе будет в 10 раз меньше?

Не стесняйся, скажи, что у тебя маленький... Хард или процессор?

Что дешевле, то и сделай :)

Прелагаю тебе осилить какую-нибудь базу данных

Хард или процессор?

Или память? Или деньги чтоб все это барахло оплатить?

Я вообще такими проектами раньше не занимался. Посему не представляю, где будет узкое место. Если база за полгода станет размером в 30 Гб, как считаешь, на 4 Гб ОЗУ она быстро будет ворочиться?

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

Да, забыл сказать.

База пока MySQL, таблицы MyISAM, запросы идут через слой абстракции ActiveRecord в Codeigniter, так что перейти на что-то более серьезное большого труда не составит.

Если база за полгода станет размером в 30 Гб, как считаешь, на 4 Гб ОЗУ она быстро будет ворочиться?

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

И если потом много-много пользователей будут часто-часто дергать данные. То потом проц кончится и все данные разархивируешь.

Не парься особо. Введи прогу в эксплуатацию «побыстрее». Если она окажется живучей, и ее не кинут по забывчивости... Потом будешь оптимизировать не на голом месте а по факту наблюдений.

Если бы Бог был, он явно этот мир не оптимизировал предварительно. А мы можем только учиться у великих мастеров :)

Ну в общем, видимо я все-таки добавлю ZIP упаковку, там всего-то пару строк в модели поправить. А структуру XML (и тем более переводить на JSON) пока трогать никак не буду, пусть просто XML упакованным хранится.

Тогда уж Protocol Buffers какой-нибудь вместо XML, да и вообще зачем хранить XML в БД? Особенно реляционной.

А зачем складывать в базу xml? Не логичнее ли распарсить и сложить непосредственно данные? Как бы хранить теги - не совсем верно, имхо.

ИМХО все зависит от того что ты с этими данными делаешь.
В этой таблице еще какие-то данные хранятся? Если да, то xml лучше в файлы складывать или отдельную таблицу. Т.к. если ты выборку по некоторым параметрам из этой таблицы делаешь (не по примари ключу) то база будет тормозить со временем.

Мы в аналогичном случае использовали гибрид SQL + NoSQL

В вашем случае XML смело кладется просто в любое NoSQL хранилище и все.

Я бы заюзал сжатие, но обязательно с хорошими хитрожопыми кешами.

Да вот уже у меня сил не осталось с NoSQL разбираться. Я понимаю что такое key-value хранилище, но не работал с ними, не знаю какие они бывают, вообще темный лес.

redis бери. Там пара типов данных и SET/GET для них. Вообще почитай что есть, возможно тебе будет проще в Key-Value хранить не сериализованные данные. Например хэши для Redis.

redis бери.

И как на редисе будет 30 гб база работать?

Ты можешь объяснить, что ты с этими данными делаешь?
30 Гб не очень большая таблица, только работать надо по примари кей и все будет ок.

Да по большей части складываю расчеты солвера, каждый расчет 32-50Кб в XML виде, которые представляют интерес примерно неделю. В день 4-5 тыщщ расчетов, итого 200Мб в день, как я и говорил.

Некоторые расчеты скажем так, интересны для истории, и к ним обращаются постоянно, их не больше 1-3%. Основная масса вообще невостребована, но они должны храниться в обязательном порядке, потому что пользователь может обратиться к какому угодно.

Примерно так.

И как на редисе будет 30 гб база работать?

есть такая вещь как шардинг, но в любом случае держать сериализованные данные в BLOB'ах идиотизм.

Никаких проблем - хранишь в отдельной таблице или можно даже файлах. Тянешь по ID - все будет летать на больших базах.
Параметры (дата отчета и все остальное) - в отдельной таблице по которой и делаешь выборку/поиск отчета.

есть такая вещь как шардинг

Шардинг для такой задачи - пушкой по воробьям. На одном небольшом сервере все будет летать.

redis бери. Там пара типов данных и SET/GET для них. Вообще почитай что есть, возможно тебе будет проще в Key-Value хранить не сериализованные данные. Например хэши для Redis.

Меня вот что смущает в Reddis:

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

Это что же получается, для базы в 30 Гб надо ставить операционку на 64 бит и 30 Гб оперативки пихать?

Никаких проблем - хранишь в отдельной таблице или можно даже файлах. Тянешь по ID - все будет летать на больших базах.

Ок, сделаю значит таблицу из двух полей - id (Primary key) и data.

Какой тип таблицы выбрать - MyISAM или InnoDB?

MyISAM быстрее, а фишки InnoDB тут не нужны.

Правда я с MySQL очень давно не работал. Поэтому лучше погугли сравнения.

Это что же получается, для базы в 30 Гб надо ставить операционку на 64 бит и 30 Гб оперативки пихать?

ну 128Гб не так уж и много ;)

Записывай в БД не XML, а серилизованные объекты, из которых ты этот XML формируешь. Изменений должно быть не много, а по объему выиграешь.

Записывай в БД не XML, а серилизованные объекты, из которых ты этот XML формируешь. Изменений должно быть не много, а по объему выиграешь.

Эээ ну тут как бы PHP особо XML не занимается, он только его передает туда-сюда между решателем на C++ и JS на фтронтэнде.

Так что промежуточно сериализивать, а потом постоянно генерить XML для запросов C++/JS - походу нагрузка на CPU будет весьма сильна. ZIP упаковка будет и то быстрее, чем алгоритм на PHP, обходящий узлы объекта/массива и генерящий XML.

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

используй mongodb, складывай туда json. будет даже индексированный поиск по всей этой фигне

используй mongodb

Нафига она тут???

я бы на твоем месте оставил все как есть - лучше упереться в диск, в его объем, чем упиреться в то что тебе таки понадобилось иметь не сжатые данные внутри базы ;)

Berkeley DB XML.

В качестве отправной точки...

Вот это — http://www.oracle.com/technetwork/products/berkeleydb/overview/index-083851.html

Да вот уже у меня сил не осталось с NoSQL разбираться. Я понимаю что такое key-value хранилище, но не работал с ними, не знаю какие они бывают, вообще темный лес.

Ну и это туда же — http://www.oracle.com/technetwork/articles/cloudcomp/berkeleydb-nosql-323570....

На самом деле, NoSQL дааавным-давно уже используется. Только народ предпочитает об этом не знать. ;)

Будете много смеяться...

... но вот MySQL для быстрой и относительно небольшой БД, я бы не рекомендовал. Berkley DB во все поля (тип базы BDB в MySQL это оно и есть, SQLite это надстройка над нею же, есть возможность писать на практически любом языке код по работе с нею, скорость просто очумевающая, особенно если оттуда убрать все упоминания об SQL и использовать API).

Для быстрой и действительно большой БД, я бы рекомендовал PostgreSQL.

По файловому хранилищу я бы рекомендовал разместить БД на xfs. Это относится к БД любого рода. В особенности, если у Вас «много чтения» при «мало записи». XFS была портирована под Linux, но писалась-то она изначально для мультимедии всяческой — много чтений из файлов довольно больших по объёму. В чём-то похоже на работу БД сч диском.

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

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