Насчет соседей по ЦОДу громко сказано. Кому нужно хакать внутри датацентра таким образом. Влезь на сам сервер и его взломать - это запросто. А слушать трафик в надежде поймать подобное межсайтовое соединение, которое является большой редкость..... Навряд ли соседи этим занимаются.
WeReng:
Можно и nginx.
Но это более геморнее по по-моему. Плюс будет задержка дополнительная: от пользователя на сервер, оттуда на другой сервер, обратно на первый сервер, обратно пользователю.
АртемЪ:
> Для первого магазина памяти 1Гб будет с большим запасом, и база будет размещаться полностью в памяти.
> Для второго магазина все хуже - два террабайта БД не запихаешь в 1гб памяти, и в 32Гб тоже.
Многие современные сервера БД возникли еще в те времена, когда 256 М на хостинге было очень много и дорого. И они неплохо оптимизированы для работы в стестенных на ресурсы условиях.
Андрей:
Я не говорю что так нельзя.
Я говорю, что можно проще - редиректом. См. рядом.
> Если сайт не сильно серьёзный и бд небольшая и не хочется сильно париться.
Вот для "небольших" и "не хочется париться" - ваш метод как раз перебор по сложности.
Для гораздо более серьезных ситуаций - согласен, нужно что-то подобное вашему предложению.
Но не для "небольших" и "не хочется париться"
АртемЪ:
> Я в курсе.
> Просто согласитесь что для одинаково эффективной работы множества пользователей с БД в 2мегабайта и для работы с БД в 2террабайта железо нужно немного разное, при одинаковой эффективности ПО.
Нет.
Подходите прагматичнее.
Зачем вам мощное железо, если основная нагрузка раз в сутки (можно по графику посещаемости найти время - глубокую ночь - когда все спят) при загрузке новых данных.
Все остальное, всю каждодневную работу сервер прекрасно выполнят практически идентично для разных сайтов.
Если мы говорим о нормально написанном и настроенном ПО.
Вы, верно, избалованы мощностью современного железа.
Не так давно серьезные вещи делались относительно шустро на компьютерах, которые слабее нынешних смартфонов.
АртемЪ:
> Как вам помогут векторные индексы, если у вас памяти мало, а база данных огромная?
Не скажу. Сами подумайте. Вы же программист.
Даю подсказку - эту проблему даже не я сам решал. Воспользовался готовым ПО.
Еще одна подсказка - значительная часть товара почти что никому кроме поисковиков не нужна. Живые люди не ищут весь товар, не говоря уже о том, чтобы его просматривать.
АртемЪ:
> Для первого магазина не нужен никакой поиск - пользователь зашел, полистал странички и оформил заказ.
> Для второго магазина пользователь сначала ищет в базе каталожный номер запчасти, потом смотрит список запчастей с этим номером, и цены на них, сравнивает и только тогда покупает.
Бы говорим о вполне конкретной ситуации.
У меня 30 000 посетителей.
15 000 товаров.
Есть и фильтрация товаров и полнотекстовый поиск.
Все работает "почти мгновенно" на значительно более слабом железе.
Поэтому я и утверждаю, что у товарища проблемы с ПО. Не нужно типичным интернет-магазинам такого железа. Если конечно у них софт корректно работает.
> Для первого магазина памяти 1Гб будет с большим запасом, и база будет размещаться полностью в памяти.
> Для второго магазина все хуже - два террабайта БД не запихаешь в 1гб памяти, и в 32Гб тоже.
БД прекрасно оптимизированы и без этого.
Более того - запихать всю БД, если это обычная БД, не так уж просто. См. выше.
Поэтому этого в реальности не происходит.
Ключевой момент, который вы упускаете - одномоментно никому не нужны все товары.
АртемЪ:
> Для первого магазина памяти 1Гб будет с большим запасом, и база будет размещаться полностью в памяти.
Специально изучал этот вопрос несколько раз.
Не все так просто, как вы думаете. Не так просто разместить всю БД в оперативной памяти, даже если памяти хватает.
Если не хочется оптимизировать ПО под это дело (переход на Tarantool, например, который прекрасно держит всю БД в оперативной памяти), то с помощью обычных SQL-серверов Вы этого не добьетесь никогда.
АртемЪ:
Для справки: сайт о котором я говорю имеет порядка 15 000 товаров.
От количества товаров в БД нагрузка НЕ ЗАВИСИТ почти никак. При поиске товаров - это не проблема - современные БД прекрасно справляются и с МИЛЛИОНАМИ записей.
Разумеется там где нужно применяется специализированная БД для полнотекстового поиска. Или как минимум, специализированный функционал вашего любимого SQL-сервера.
Просмотр товара тоже не дает нагрузки - ни один покупатель не будет лопатить десятки тысяч товаров.
Что меняется: нагрузка при большом количестве товаров - только при обновлении БД. Раз в сутки. Решается правильными (удобными и быстрыми) способами импорта.
С картинками тоже проблем нет. Они живут на отдельно сервере, в отдельном датацентре на cloud storage hosting. За картинки плачу порядка 1000 рублей в год. Да, не ослышались.
Сравнение по характеристикам? Ну откройте же наконец для себя векторные индексы. Тогда сервер может сравнивать за секунды сотни товаров - но процессор даже не вспотеет.