Как обеспечить быструю работу сайта с большой базой данных?
Для магазина нужно сделать систему менеджмента инвентаря, буду искать разработчика, сейчас составляю ТЗ. Задумался вот, что я, возможно, не до конца понимаю, как описать стабильность системы в ТЗ. А разработчик ещё неизвестно какой попадётся.
Дело в том, что магазин специффический, у каждого товара есть уникальная характеристика, и сейчас их под 300 000, до конца года думаю будет под миллион, и количество дальше будет постоянно расти. У этих характеристик есть штук 10 схожих данных, вроде названия товара, даты добавления, статуса и т.д., но объём всё-равно очень большой. Поменять это никак нельзя. Будут и другие таблицы, но они сравнительно небольшие.
Я думал, что решение можно делать на laravel + mysql. Для меня хорошо, так как сам поверхностно понимаю, как это работает. Но сможет ли этот фремворк стабильно обрабатывать такие объёмы данных? Где тут вообще могут быть подводные камни?
Очень важно, чтобы система работала шустро и очень стабильно.
jabrik, не стОит тыкать пальцем в небо только по тому, что где-то что-то слышали от занкомого знакомых...
в частности из недостатков постгреса как раз:
Когда не стоит использовать PostgreSQL
Скорость: если всё, что нужно — это быстрые операции чтения, не стоит использовать PostgreSQL.
Простые ситуации: если вам не требуется повышенная надёжность, поддержка ACID и всё такое, использование PostgreSQL — это стрельба из пушки по мухам
Думаю, в данном случае важно выбрать грамотного подрядчика. Я много сайтов повидал на своём веку, но в 95% они были написаны криво, толковых разработчиков по пальцам сосчитать можно, и они как правило стоят дороже "$100 за сайт" (излюбленная фраза заказчиков на фрилансе:)
Буквально вчера оптимизировал крупный американский сервис. Задача - страница открывается более 15 секунд. Простой анализ слоулогов и банально правильная индексация позволили уменьшить время загрузки до 0,6 секунд, а это элементарные вещи, который обязан знать любой разработчик.
Просто, когда будешь искать заказчика, требуй его портфолио с высоконагруженными проектами. Можешь поинтересоваться, например: "хм, я вижу у вас на сайте много товаров с большим количеством параметров у каждого. Расскажите, как вы строили sql-запрос и какое примерно время запроса в базу получилось при этом. Как вы добились такого хорошего времени?". По его ответу, даже если сам не понимаешь половину слов, будет видно, в теме он, или не очень.
Оставьте выбор технологий на подрядчика ибо у вас знаний примерно на уровне плинтуса по данному вопросу. Пропишите Quality Attributes для приемки. Если все нужные нагрузочные тестирования будут выполнены то пусть хоть на файлах работает)
PS про файлы, конечно, перебор, но кто мешает в требования в ТЗ написать ограничения на те же технологии. Как пример, реляционная бесплатная база данных с LTS не менее до 2040 года. А какая будет - после этого уже не так важно. С языком программирования та же история
Фреймворк тут вообще не при чём. Это вопрос правильной организации структуры БД, настроек, и индексов.
1 миллион - это не много. Я бы всё же взял PostgreSQL, и меняющиеся характеристики хранил бы, в jsonb поле c GIN индексом на нём.
Остальное зависит от конкретных задач, но у меня на одном проекте, поиск по 600к таких индексированных JSON'ов занимал ~10мс.
Так что и с миллионом проблем не будет. А вот при кривой структуре, и запросах... Я видел магазин который при 70к товаров пагинацию генерил 4 минуты. На шаред хостинге правда, на простеньком сервере было уже 8 секунд, что впрочем тоже ни в какие ворота.
Если сильно не углубляться - то делать как делается. База выдержит без проблем и лям записей. Если будет проблема - добавить индексы. Если будет много лишних данных написать чистилку старых записей. Вообще все проекты которые развиваются база всегда растет - это нормально.
Средний
