Которая 15м записей

ага, понял, ну я её думал просто сделать Memory (сейчас это две обычные таблицы InnoDB)

Я бы вопрос оптимизаций вида "что сделать in-memory/NoSQL/денормализованным" оставил на потом. А для начала разобрался бы сколько, откуда и с какой частотой будет качаться.

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

Спасибо за информацию! И всем остальным участникам тоже!:)

Ещё такой вопрос, а в какой именно момент MySQL грузит винт? Она не может мне лишнюю нагрузку как-то делать на каждой строке записи, а не писать их пачками? Или если я гружу данные с помощью LOAD DATA LOCAL INFILE, то MySQL по-любому грузит данные пачками и лишний раз к винту не обращается?

Можно попытаться. Надо в память всё засунуть и с памятью работать. Как это сделать - это уже вопрос к Вам.

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

Скорей всего 2-ое, но я в MySQL не понимаю ничего)

Когда ты грузишь данные, СУБД всё равно должна простраивать индексы. Сами данные ты можешь вгружать практически со скоростью твоего винта. Но если есть индексы (в т.ч. констрейнты и т.д.), то они будут перестраиваться, а это резко снизит скорость загрузки.

Кроме того, если у тебя в тоже самое время пользователи регулярно ищут на бесконечную глубину, то у тебя найденные по индексам данные будут физически доставаться с диска, что будет аффектить скорость записи даже с SSD.

Также ЕМНИП нужно следить, что бы ролбэки были редки.

да, индексы есть, причем в Таблице 2 (бОльшей) - 10 индексов. А можете ещё, пожалуйста, для чуть более тупых объяснить, что такое "поиск на бесконечную глубину"?

та можно, возможно сервер и проапгрейдю в любом случае, но я всё равно верю, что что-то не так с кодом и/или нестройками

ааа, в смысле, что каждый поиск может затрагивать всю таблицу полностью?

Тогда у нас просто нет информации, чтобы помочь Вам

Может всё таки решить архитектурно и вынести данные для поиска в другое место? Тогда будет меньше конфликтов

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

Да тут не то, чтобы конфликты, тут железо не справляется

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

Вы задачу не так описывали. По вашей задаче у Вас должно быть в день 300 загрузок.

Их можно делать послдеовательно хоть в один воркер.

пусть оно хоть на одной загрузке перестанет тормозить:)

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