Хранение большого объема данных

Рекомендуем Вам завязать с религиозным фанатизмом. Понравилось Вам innodb когда-то - Вы молодец. У myisam есть + и - по сравнению с innodb, если Вы отложите на минутку свой религиозный фанатазим и попробуете вникнуть в суть - Вы это поймете. Пока же похоже Вам интересно не столько разобраться в вопросе, сколько поспорить ради спора - что в свою очередь неинтересно нам. Поэтому извините, но дальше объяснять что-то не видим смысла.

edogs, не-не, религиозный фанатизм это не про меня. Я придерживаюсь мировой практики в разработке, знаю что такое trade off при выборе какого-то инструмента. Я привел вам доводы, почему InnoDB лучше в данном случае. От вас я пока услышал только вот это:

У вас все относительно. Небольшой и средний сбой - нет такой классификации. Есть битые индексы, есть умерший диск, и т.д. Что такое "небольшой" и "средний" сбой известно только вам, как, в прочем, и "относительно простые запросы".

Ну и NoSQL вы предложили, не я, так что с религиозным фанатизмом вы явно не по адресу.

Когда приведете хоть один довод, почему MyISAM в данном случае лучше, тогда и будет вам

По поводу содержимого.

Будет часть статичных полей, которые я извлеку и буду записывать в базу.

То что будет в JSON - там информация о товаре или списке товаров.

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

Там, где товар - тоже куча параметров с небольших количеством текста, и поле с описанием товара. Оно может содержать текст, но не очень много.

---------- Добавлено 28.04.2019 в 15:19 ----------

Мне не очень нравится то, что InnoDB хранит все в одном файле. Уже попадал с этим.

danforth, еще раз - спор ради спора нам не интересен, равно как и Ваш набор лозунгов (без их понимания) про современность и блабла, спасибо. Чем myisam может быть лучше в данном случае уже писали, добавим впрочем еще - бакапить проще.

Тут вопрос не в том какое у Вас содержимое, а что Вы с ним собираетесь делать.

Если только доставать по ИД, то нет смысла городить огород с кучей полей. Пихайте все в blob и все.

А вот если при выборке у Вас будут поля по которым будет сортировка или фильтрация - тут уже надо выносить их отдельно и думать как.

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

Скорее всего после переезда в БД всё умрет вообще...

Если вам де-факто не нужны сложные поиски (а судя по тому, что всё в файлах не нужны), то яб грёб в сторону рассматривания файловой системы и подбора лучшей для ваших задач. Они реально разные, и реально по-разному работают, мне попадалось даже что-то специализированное...

Тут реально большого буста тюнингом добиться.

БД как вы понимаете могут быть оптимизированы либо на запись, либо на выборку.

И если у вас быстро меняется содержимое, а сложные выборки не нужны, то в любом случае будет проигрышь.

В общем-то файловая система та-же БД, но гораздо аккуратнее написанная и оптимизированная под операции.