rpiontik Sep 25 2018 at 22:17

Сложное решение простых проблем HighLoad WEB-сервисов

4 min

Client optimization*Algorithms*Server optimization*Cryptocurrencies

Comments 11

Moxa Sep 26 2018 at 00:35

Сколько у вас данных в базе, что нужно заморачиваться таким экзотическим кешированием? Не проще все в память положить?

rpiontik Sep 26 2018 at 00:55

Мы используем механизм из первой статьи. Он очень прост. А этот для нас избыточен. Возможно, он будет применен в аналитической подсистеме в будущем. Данная статья — развитие идеи. Она возникла по итогу комментариев к первой. Там мне пытались доказать, что это "прибитое к nginx гвоздями решение" и что оно не имеет запаса "гибкости". В какой-то степени, просто гештальт закрыл для себя.

Moxa Sep 26 2018 at 12:40

так сколько у вас данных? неужели действительно не влезет в память?

bcmob Sep 26 2018 at 12:45

Несмотря на кучу негатива в комментариях к первой статье, я просто зашёл биржу с профиля и увидел разницу в работе с другими аналогичными. И точно такая система, описання теперь, у меня реализовалась в мозгу после прочтения предыдущей статьи.

rpiontik Sep 26 2018 at 12:52

+100 Мне казалось, что эта статья по лишняя. Что первой вполне достаточно для предоставления базы, которую уже может развить любой, в нужно направлении. Но… как вы правильно отметили, комментарии к прошлой статье показали обратное. Я откровенно рад, если наш опыт кому-то окажется полезен.

Moxa Sep 26 2018 at 17:32

поделитесь пожалуйста ссылкой, никак не могу найти

rpiontik Sep 26 2018 at 12:47

Возможно я не понимаю Вас, но причем тут память? Вы статику в память хотите запихнуть? Зачем? Есть CDN который сам решает как ему эти файлы хранить. В памяти или на диске. Мы находимся за ним.

Закешировать запросы? Ну так я, мне кажется наглядно на это дал пояснения в статье. И положив что-то в память, это никак не решит вопрос.

Уж тем более это никак не решит вопрос количества запросов. Даже если предположить, что данные находящиеся в памяти решают проблему времени доступа к ним, то что с количеством соединений?

Плз, посмотрите цели которые я ставлю в статье, и если вы видите как их достичь просто положив что-то в память, я с удовольствием отражу это в статье как альтернативное решение. Ну или вообще признаю статью несостоятельной для приведенных условий.

to Moxa

Moxa Sep 26 2018 at 17:28

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

rpiontik Sep 26 2018 at 17:46

Т.е. если на дохлой VPS (2400core, 512кб ОЗУ, 10Гб HD) с каналом 100мб, мы запихнем все в память… и можно отказаться от CDN? Верно? Доступ к данным будет для всех одинаково скор, хоть в Африке, хоть в Европе? Ну и DDoS (шквальную нагрузку запросами) мы легко переживем? А падение этого сервера невероятно, т.к. все лежит в памяти. Я ничего не упустил?

maydjin Sep 27 2018 at 12:30

Но замеров — так и не представили...

Говорят, что очевидно, что mergesort лучше quicksort, а поддерживать отсортированный массив пар цена/количество это убого по сравнению с красночёрным деревом и уж тем более хэш таблицей. И эти утверждения даже строгие доказательства имеют.

Но на практике, c++ реализация quicksort, проходит тесты для mergesort для остальных языков на том же stepic'e. А за хранение аггрегированной буки до 10000 элементов в хэш таблице, в приличном обществе, можно и в глаз получить.

rpiontik Sep 27 2018 at 14:37

Будет время — сделаю.

Но на практике, c++ реализация quicksort, проходит тесты для mergesort для остальных языков на том же stepic'e. А за хранение аггрегированной буки до 10000 элементов в хэш таблице, в приличном обществе, можно и в глаз получить.

Мне кажется, это как определять степень влажности по итогу сравнения объемов мокрого с теплым… в целом я не против такого механизма, если его используют другие.

Show the best of all time