Приветствую, пишем сайт, где будет некое подобие каталога с объектам, поставщики размещают объекты, покупатели ищут их в каталоге. Все объекты привязаны к конкретному адресу. Используется PHP+MySQL. Основная нагрузка будет создаваться при обновлении фильтров каталога и расчете расстояний между объектами.
В процессе возникли вопросы:
1. Как сделать выбор объектов в N-радиусе от указанного места?
Пользователь указывает произвольный адрес и допустим +30 км от него вокруг. Можно ли это сделать через Яндекс.Карту, проставив все точки на ней, и проверить полигон на вхождение точек внутри? Точнее не так, это можно, но объектов в каталоге будет около 500 000. Выдержит ли Яндекс.Карта столько объектов и манипуляции по расчетам? Есть ли какие то другие способы?
2. Подойдет ли для целей проекта PHP и MySQL?
В смысле пишутся вообще такие вещи на PHP? Есть какие-либо цифры по тому, сколько пользователей будет держать сайт? Я понимаю, что все зависит от "прямых" рук и все такое, но все же, какой потолок производительности у скриптов PHP и сколько пользователей за день/одновременно они выдержат? Предположительная максимальная нагрузка 100 000 хостов в день/30 000 хостов одновременно.
Полная Версия: Разработка высоконагруженного проекта
| Цитата (freeeeez @ 18.11.2015 - 06:33) |
| Пользователь указывает произвольный адрес и допустим +30 км от него вокруг |
Есть формула по которой можно извлечь данные из базы в определенном радиусе от текущего.
| Цитата (freeeeez @ 18.11.2015 - 06:33) |
| Точнее не так, это можно, но объектов в каталоге будет около 500 000. Выдержит ли Яндекс.Карта |
Если все сразу вывести обычными метками, то клиент загнется и будут жуткие тормоза. Для множества объектов на карте лучше использовать тайлы.
| Цитата (freeeeez @ 18.11.2015 - 06:33) |
| Есть какие-либо цифры по тому, сколько пользователей будет держать сайт? |
Зависит от многих факторов, используемого железа, архитектуры приложения и т.д.
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
freeeeez, вы про серверное железо слышали? Узкое место - это железо на котором работают php и mysql , а не они сами. Если у вас MySQL не справляется с обраборткой данных, то это железо слабое, а не мускул херовый. Кривые руки естествнно в расчёт не берём.
В свете вышеизложенного теперь спросите у себя сами сколько выдержит MySQL?
_____________
Стимулятор ~yoomoney - 41001303250491
В свете вышеизложенного теперь спросите у себя сами сколько выдержит MySQL?
_____________
Стимулятор ~yoomoney - 41001303250491
| Цитата (freeeeez @ 18.11.2015 - 10:33) |
| Предположительная максимальная нагрузка 100 000 хостов в день/30 000 хостов одновременно. |
Что такое "хост" в Вашем понимании, в контексте?
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
| Цитата (S.Chushkin @ 18.11.2015 - 09:50) |
| Что такое "хост" в Вашем понимании, в контексте? |
| Цитата (T1grOK @ 18.11.2015 - 06:47) | ||||||
Есть формула по которой можно извлечь данные из базы в определенном радиусе от текущего.
Если все сразу вывести обычными метками, то клиент загнется и будут жуткие тормоза. Для множества объектов на карте лучше использовать тайлы.
Зависит от многих факторов, используемого железа, архитектуры приложения и т.д. |
А можно поподробнее про формулу? Без карты можно обойтись получается?
Valick, вы всегда выбираете между: ответить нормально и ответить с сарказмом?
Вот S.Chushkin вроде глупейший вопрос задал, а вы ему нормально ответили, может и мне подскажите?
Я не идиот, про железо слышал, но я не разбираюсь в этом. Может вы какой-то конфиг на вскидку скажете, который выдержит указанные нагрузки.
Вот S.Chushkin вроде глупейший вопрос задал, а вы ему нормально ответили, может и мне подскажите?
Я не идиот, про железо слышал, но я не разбираюсь в этом. Может вы какой-то конфиг на вскидку скажете, который выдержит указанные нагрузки.
| Цитата (freeeeez @ 18.11.2015 - 10:01) |
| Valick, вы всегда выбираете между: ответить нормально и ответить с сарказмом? |
не всегда есть время на нормальный ответ
На счёт конфига не скажу, но мне кажуться ваши опасения преждевременны.
Если нет ошибок в архитектуре приложения, то всё "умощьняется" по средствам железа и масштабируемости.
_____________
Стимулятор ~yoomoney - 41001303250491
freeeeez, самый простой вариант - это заранее определить все расстояния между всеми объектами и положить их в базу данных. А потом получать их простым запросом.
| Цитата (kaww @ 18.11.2015 - 07:09) |
| самый простой вариант - это заранее определить все расстояния между всеми объектами и положить их в базу данных |
Ужс...Сколько же придется сделать манипуляций с базой в случае мелких изменений. Смена расположения одного из объектов и тд.
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
| Цитата (T1grOK @ 18.11.2015 - 07:16) |
| Сколько же придется сделать манипуляций с базой в случае мелких изменений. |
Скорее всего характер данных подразумевает, что изменения будут вносится редко, и что запросов на поиск будет много больше чем на обновление.
Теоретически.
А можно ведь хранить координаты объекта. И поиск осуществлять по формуле от текущей координаты.
А можно ведь хранить координаты объекта. И поиск осуществлять по формуле от текущей координаты.
Microsoft SQL Server 2008+ (geography)
PHP.
PHP.
| Цитата (freeeeez @ 18.11.2015 - 11:01) |
| Вот S.Chushkin вроде глупейший вопрос задал, а вы ему нормально ответили... |
Может и глупейший, но правильный.
Для "нагруженности" не имеет значения сколько у вас посетителей, важны только два параметра: число генерируемых страниц и число хитов, в единицу времени.
Если код нормальный, структура БД правильная, запросы SQL оптимальные, то два средних сервера (http + mySQL) отработают ~5 млн. страниц/сутки.
Хиты, - зависит от содержания страницы. При малом количестве статики (<=10/страницу) и их небольшом размере http-сервер справится.
И пофиг, кто будет запрашивать это - 5 млн. "хостов" или 1.
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
Здесь расположена полная версия этой страницы.