@Coder321

Как организовать высоконагруженый проэкт на ноде?

Планируется проект на ноде у которого будет примерно 2-3 тис запросов в секунду. Каждый запрос будет отдавать какой то файл. Каждая отдача файла должна записываться в лог и в итоге собираться статистика для каждого файла. Как я вижу это:
будет маасив с 60-тью вложенеми массивами, каждый вложеный массив будет соответствовать одной секунде. В каждый из этих массивов будет пушится обьект со статистикой. При достижерии 60-го элемента массив будет отправлятся на запись в бд и обнулятся.
Так как ни когда не делал столь нагруженые проекты возникло несколько вопросов:
1. Правильна ли сама задумка? Если нет, то что можете предложить?
2. Какую бд использовать?
3. Правильно ли для хранения минуты использовать массив? Все таки если за эту минуту произойдет какой то сбой, то вся статистика за эту минуту потрется.
4. Что делать с таблицей минут, ведь она будет сильно разростаться?
5. Как имитировать 2-3 тысячи запросов для тестирования?
6. И на последок, какие можете дать советы для реализации такого проекта?

P.S. Для тех кто будет писать что нода не для отдачи статики, прихоть не моя. а заказчика.
P.S. Работал только с монгой и то на базово/среднем уровне.
  • Вопрос задан
  • 495 просмотров
Пригласить эксперта
Ответы на вопрос 4
Falseclock
@Falseclock
решаю нестандартные задачи
Не с той стороны подошли к архитектуре. При организации БД думать нужно в первую очередь не как хранить, а как потом использовать, а метод хранения сам отрисуется.
Кто, как, при каких обстоятельствах данные будет использовать?
Ответ написан
2-3 тысячи в секунду?
Новая заведомо успешная соц.сеть?
Ответ написан
@rPman
Либо вы гарантированно сохраняете события но медленно их обрабатываете либо наоборот.
Для начала не усложняйте систему - попробуйте писать в лог на каждое событие, если скорости диска будет не хватать, изменить способ хранения, последовательно исключая то что тормозит (например файловую систему, при записи в файл реально происходит несколько операций, в т.ч. в разных частях диска).
upd: 16байт записи, дешевый ssd+ntfs:7674 rec/sec, старый hdd+ntfs:425 rec/sec

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы