Придет время, когда откажутся от избыточной микросервисности и вернутся к классике "Premature optimization is the root of all evil".
По этой логике следовало сначала выпустить первую версию, снять стату, может даже не пришлось бы сервис развивать, а закрыли бы за ненадобностью. Неужели нельзя было мертики снимать Яндекс.Метрикой?
Как я понял, автор публикует серию статей, начал с азов. Будьте терпеливее и терпимее.
А в медицине машинное обучение используется для ускорения подбора/перебора препаратов.
Первая задача решается аналитически, см. выше https://habrahabr.ru/post/311908/#comment_9845206
Вторая и третья задача содержат факториал и степени на больших числах, что уже должно останавливать от попытки решать тупым перебором.
Во второй надо разложить на множители x1^s1, ..., xk^sk: т.е. надо s1 штук x1,… И надо перебирать от 1 и далее числа, так же раскладывая на множители, и вычитать соответствующее количество, пока требуемое число si для всех xi не наберем. И так для диапазона чисел.
Третий если перебирать то хотя бы как в https://habrahabr.ru/post/311908/#comment_9851084
Иначе можно разложить на множители число A и кодировать степени в строку и вставлять строки в контейнер. Пример: 6^3=2^3*3^3, или 8^3=2^9.
Классические работы на тему визуализации данных рекомендуют не использовать пайчарты когда долей больше 3-4.
Они у вас совсем не к месту — просто мусор.
tnt_pass ожидаемо дает больше, т.к. в этом случае:
1. http часть работ вынесена в nginx
2. запросы идут мультиплексом, т.е. batch
Это и показывает, что тесты из статьи в основном
— тестируют реализацию http, а она там в том же потоке луа работает.
— не загружают сам тарантул, утыкаясь в узкое горлышко на http уровне.
Вывод: для http лучше использовать nginx модуль с tnt_pass.
Может вы достанете птицу феникса? (я про javascript)
Его знают многие, его изучение оправдано с так же с использованием на клиент сайде, да и нода-пользователи…
Как я понял, тест был многопоточный и запросы шли один за другим.
1. При таком подходе сетевой стек линукса довольно быстро ограничит RPS еще до того как все CPU будут использованы (речь про средние сервера, а не десктоп).
2. Тарантул хорошо себя показывает в batch запросах, где пачками грузятся запросы, и так же пачками получаются ответы. Но при этом сами запросы должны быть простые: не более одного меняющего данные операции (в CALL) для 1.5 или же нужно использовать транзакции в 1.6.
3. Плохое использование ядер окупается ускорением за счет отсутствия локов. На практике это надо мерить, но любители корутин/файберов будут бить в грудь даже без тестов (что обычно бывает оправданным).
Протестируйте на таких кейсах как batch запросы, используя его бинарный протокол. На таких кейсах он наверняка обгонит что-то самописное.
Надо понимать, что дает конкретное СУБД и чем за это придется платить. Для каждой базы есть как свои плюсы, так и свои минусы.
И я с этим согласен.
Тарантул не потребляет все ядра эффективно, на серверах у нас их 12*2HT.
В этом случае частый ответ разработчиков: запустить несколько инстанцев.
Такое разделение
— резко снижает объем памяти одного инстанца, т.к. они его между собой не шарят,
— требуется писать код шардинга, и, иногда, стыковать данные из разных шардов.
Проблему неиспользованных ядер в целом можно решить, если на тот же сервер сажать еще какие-то демоны, тот же Nginx, например.
Странное рассуждение.
Переписать любого размера кусок системы требует собственное переписать, протестировать, интеграционный тест, нагрузочный тест,… дополнительное железо и среда для нового,…
И стоит оценить, сколько профита это даст. Я думаю, они там не раз это считали и обсуждали.
Сравнивал (мемкеш, монго, мускуль, редис, токио кабинет), но расписывать все не хочу, могу ответить по конкретным конкурентам, про которые вы хотели бы знать.
Я использую в продакшене: 4 сервера в кластере с 96Gb, суммарно 320Gb памяти под тарантулы.
Хранятся порядка 5 млрд записей, в среднем по 40 байт. Uptime 2 года без без каких либо вмешательств и обновлений.
Никакая база так эффективно не может хранить столько мелких данных так эффективно в оперативке.
Бизнес логика зашита в lua процедурах, и запросы идут в batch режиме.
Если бы не было lua процедур, batch режим был бы не доступен, т.к. изменение данных зависят от других данных в базе: пара селектов и один апдейт. Это было бы 3 раунд-трипа на одну операцию изменения, а тут удается упаковать 50 операций в один раунд-трип.
Хочется лишь сказать: всё циклично!
Придет время, когда откажутся от избыточной микросервисности и вернутся к классике "Premature optimization is the root of all evil".
По этой логике следовало сначала выпустить первую версию, снять стату, может даже не пришлось бы сервис развивать, а закрыли бы за ненадобностью. Неужели нельзя было мертики снимать Яндекс.Метрикой?
А в медицине машинное обучение используется для ускорения подбора/перебора препаратов.
Вторая и третья задача содержат факториал и степени на больших числах, что уже должно останавливать от попытки решать тупым перебором.
Во второй надо разложить на множители x1^s1, ..., xk^sk: т.е. надо s1 штук x1,… И надо перебирать от 1 и далее числа, так же раскладывая на множители, и вычитать соответствующее количество, пока требуемое число si для всех xi не наберем. И так для диапазона чисел.
Третий если перебирать то хотя бы как в https://habrahabr.ru/post/311908/#comment_9851084
Иначе можно разложить на множители число A и кодировать степени в строку и вставлять строки в контейнер. Пример: 6^3=2^3*3^3, или 8^3=2^9.
Они у вас совсем не к месту — просто мусор.
1. http часть работ вынесена в nginx
2. запросы идут мультиплексом, т.е. batch
Это и показывает, что тесты из статьи в основном
— тестируют реализацию http, а она там в том же потоке луа работает.
— не загружают сам тарантул, утыкаясь в узкое горлышко на http уровне.
Вывод: для http лучше использовать nginx модуль с tnt_pass.
Его знают многие, его изучение оправдано с так же с использованием на клиент сайде, да и нода-пользователи…
1. При таком подходе сетевой стек линукса довольно быстро ограничит RPS еще до того как все CPU будут использованы (речь про средние сервера, а не десктоп).
2. Тарантул хорошо себя показывает в batch запросах, где пачками грузятся запросы, и так же пачками получаются ответы. Но при этом сами запросы должны быть простые: не более одного меняющего данные операции (в CALL) для 1.5 или же нужно использовать транзакции в 1.6.
3. Плохое использование ядер окупается ускорением за счет отсутствия локов. На практике это надо мерить, но любители корутин/файберов будут бить в грудь даже без тестов (что обычно бывает оправданным).
Протестируйте на таких кейсах как batch запросы, используя его бинарный протокол. На таких кейсах он наверняка обгонит что-то самописное.
Надо понимать, что дает конкретное СУБД и чем за это придется платить. Для каждой базы есть как свои плюсы, так и свои минусы.
Тарантул не потребляет все ядра эффективно, на серверах у нас их 12*2HT.
В этом случае частый ответ разработчиков: запустить несколько инстанцев.
Такое разделение
— резко снижает объем памяти одного инстанца, т.к. они его между собой не шарят,
— требуется писать код шардинга, и, иногда, стыковать данные из разных шардов.
Проблему неиспользованных ядер в целом можно решить, если на тот же сервер сажать еще какие-то демоны, тот же Nginx, например.
Не стоит предлагать неверную замену кода в статье, даже если вы написали "что-то вроде".
Люди скопируют ошибочный код, результат не предсказуем.
Переписать любого размера кусок системы требует собственное переписать, протестировать, интеграционный тест, нагрузочный тест,… дополнительное железо и среда для нового,…
И стоит оценить, сколько профита это даст. Я думаю, они там не раз это считали и обсуждали.
Хранятся порядка 5 млрд записей, в среднем по 40 байт. Uptime 2 года без без каких либо вмешательств и обновлений.
Никакая база так эффективно не может хранить столько мелких данных так эффективно в оперативке.
Бизнес логика зашита в lua процедурах, и запросы идут в batch режиме.
Если бы не было lua процедур, batch режим был бы не доступен, т.к. изменение данных зависят от других данных в базе: пара селектов и один апдейт. Это было бы 3 раунд-трипа на одну операцию изменения, а тут удается упаковать 50 операций в один раунд-трип.
Активность языка Lua заметно выше чем у Haskell