Спасибо за интересную статью по теме нагрузочного тестирования. Хотелось бы уточнить вот этот момент:
Хранить пул подключений к базе данных как глобальную переменную — плохая практика.
Это спорный момент. Дело в том, что я не наблюдаю единого мнения в этом вопросе. Например, если вы хотите эмулировать честных виртуальных пользователей, то у каждого должен быть свой пул подключений. А для этого как раз нужно указывать пул как глобальную переменную.
Добрый день! Мы параллельно и независимо проделывали те же упражнения по выбору утилиты и пришли к тому же результату -- K6. Коллеги рассматривали в том числе jmeter три года назад.
Также есть другие подробные статьи со сравнениями:
Наша база данных поддерживает ACID транзакции, … но транзакции поддерживаются только в рамках узла …
На самом деле в кластерном решении достаточно часто хватает транзакции в рамках узла. Это связано с тем, что при проектировании стараются избежать map-reduce-ов и стараются размещать связанные данные рядом, на одном узле. Конечно при этом нужно много чего учитывать и это не удобно. Было бы хорошо иметь кластерную транзакцию. Но пока её нет.
Вы правы, конечно же стоило написать иначе. Я имел ввиду, что из коробки перечисленные реляционки - не кластер. Но настроить из них кластер вполне можно, только это требует дополнительной экспертизы. Я вычитывал текст много раз и как-то это пропустил. Извините.
Спасибо, что поделились интересным опытом. Просто интересно - а для чего могут быть нужны такие большие таблицы без первичного ключа? Это исторические данные какие-то?
Решение о сжатии не принимается "на лету". Решение о сжатии (жать или не жать и чем) принимается на этапе построения архитектуры приложения на основании сведений о среднестатистическом характере входных данных.
Прикольная идея - динамическая архитектура сжатия, если я правильно понял. Уверен, мои коллеги оценят. Мне с одной стороны нравится, но с другой же - не хотелось бы видеть такой модуль на своих проектах. Объясню почему.
Мне нужно будет оборудовать кластер под все три модели. Выделить ресурсы и так далее. А что, если модуль будет всегда выбирать только один вариант архитектуры? Что будет происходить при переключении между моделями? А нужно ли этот процесс мониторить?
С другой стороны, если я могу назвать коэффициенты, я тогда могу сразу определить нужную из трёх архитектуру. Я могу контролировать число экземпляров кластера и их роли. Мне легче один раз задать конфигурацию под нужную задачу. Я хочу простоты. Простота - это надёжность.
Спасибо за вопрос. Речь, видимо, про BSON. Давайте представим два случая. В первом случае мы просто сжимаем строку. Во втором случае мы преобразуем JSON в BSON и потом сжимаем. Дело в том, что и в первом и во втором случае получится плюс-минус такой же результат. Во втором случае просто степень сжатия будет меньше.
Простите, а вам какая религия не позволяет использовать что-то, кроме PostgreSQL? Из вашего второго примера я не увидел, что оно быстрое. Из статьи понятно, что оно отзывается за несколько миллисекунд, а какую нагрузку может выдерживать - непонятно. Автор же показал конкретный работающий стенд.
Нельзя сказать, что Tarantool прям необходим на небольшом проекте - серверную часть можно написать на чём угодно.
Вот Вы говорите "классический вариант", а я не знаю точно, что Вы имеете ввиду. Есть где-то руководство, где написано, как делать классический вариант? Чем классический вариант лучше или предпочтительнее остальных?
Тем не менее, Tarantool удобен - что бы реализовать какой-то концепт не нужно много кода. Он даёт большой потенциал роста - если проект вырастет, будет несложно его масштабировать. Впоследствии, можно будет докрутить и тот же nginx (если он понадобится) и всё что нужно ещё.
Отвечая на вопрос - выбор инструмента это всегда вопрос предпочтений, но если небольшой проект может вырасти, то имеет смысл написать его, используя Tarantool.
На мой взгляд это зависит от задачи. Если у меня небольшой проект - всё, что я хочу сделать - это запустить ровно одну команду на сервере. И получать команды снаружи я хочу ровно в том виде, как мне удобно. Я не хочу настраивать nginx и всё остальное прочее.
Прикольно. Я вот не знал про такую технологию у MS SQL сервера. Она вряд ли пригодится, но для общего развития интересно. У нас картинки хранятся на диске. В базе только их имена.
Добрый день!
Спасибо за интересную статью по теме нагрузочного тестирования. Хотелось бы уточнить вот этот момент:
Это спорный момент. Дело в том, что я не наблюдаю единого мнения в этом вопросе. Например, если вы хотите эмулировать честных виртуальных пользователей, то у каждого должен быть свой пул подключений. А для этого как раз нужно указывать пул как глобальную переменную.
Можете подсветить своё видение вопроса?
Добрый день!
Мы параллельно и независимо проделывали те же упражнения по выбору утилиты и пришли к тому же результату -- K6. Коллеги рассматривали в том числе jmeter три года назад.
Также есть другие подробные статьи со сравнениями:
Comparing k6 and JMeter for load testing
Сравнение JMeter и k6 на практике
Простое должно быть простым: «Легкий» Load Testing
По базам формулировку поправил, спасибо, что не прошли мимо, а то бы так и висело 🙈
На самом деле в кластерном решении достаточно часто хватает транзакции в рамках узла. Это связано с тем, что при проектировании стараются избежать map-reduce-ов и стараются размещать связанные данные рядом, на одном узле. Конечно при этом нужно много чего учитывать и это не удобно. Было бы хорошо иметь кластерную транзакцию. Но пока её нет.
Сложно сказать, ведь наш продукт использует далеко не только VK
Вы правы.
Вопрос в том, сколько раз нужно проделывать это упражнение.
Вы правы, конечно же стоило написать иначе. Я имел ввиду, что из коробки перечисленные реляционки - не кластер. Но настроить из них кластер вполне можно, только это требует дополнительной экспертизы. Я вычитывал текст много раз и как-то это пропустил. Извините.
Почему?
Очевидно пропущена цифра после запятой
Не должен. Алерт бы дал знать, что там что-то не так )
Спасибо, что поделились интересным опытом. Просто интересно - а для чего могут быть нужны такие большие таблицы без первичного ключа? Это исторические данные какие-то?
Решение о сжатии не принимается "на лету". Решение о сжатии (жать или не жать и чем) принимается на этапе построения архитектуры приложения на основании сведений о среднестатистическом характере входных данных.
Мне тут коллеги подсказали, что внутри Tarantool так и хранит - в бинарном формате msgpack.
Прикольная идея - динамическая архитектура сжатия, если я правильно понял. Уверен, мои коллеги оценят. Мне с одной стороны нравится, но с другой же - не хотелось бы видеть такой модуль на своих проектах. Объясню почему.
Мне нужно будет оборудовать кластер под все три модели. Выделить ресурсы и так далее. А что, если модуль будет всегда выбирать только один вариант архитектуры? Что будет происходить при переключении между моделями? А нужно ли этот процесс мониторить?
С другой стороны, если я могу назвать коэффициенты, я тогда могу сразу определить нужную из трёх архитектуру. Я могу контролировать число экземпляров кластера и их роли. Мне легче один раз задать конфигурацию под нужную задачу. Я хочу простоты. Простота - это надёжность.
Спасибо, что поделились мыслью.
Спасибо за вопрос. Речь, видимо, про BSON.
Давайте представим два случая. В первом случае мы просто сжимаем строку. Во втором случае мы преобразуем JSON в BSON и потом сжимаем. Дело в том, что и в первом и во втором случае получится плюс-минус такой же результат. Во втором случае просто степень сжатия будет меньше.
Простите, а вам какая религия не позволяет использовать что-то, кроме PostgreSQL? Из вашего второго примера я не увидел, что оно быстрое. Из статьи понятно, что оно отзывается за несколько миллисекунд, а какую нагрузку может выдерживать - непонятно. Автор же показал конкретный работающий стенд.
Нельзя сказать, что Tarantool прям необходим на небольшом проекте - серверную часть можно написать на чём угодно.
Вот Вы говорите "классический вариант", а я не знаю точно, что Вы имеете ввиду. Есть где-то руководство, где написано, как делать классический вариант? Чем классический вариант лучше или предпочтительнее остальных?
Тем не менее, Tarantool удобен - что бы реализовать какой-то концепт не нужно много кода. Он даёт большой потенциал роста - если проект вырастет, будет несложно его масштабировать. Впоследствии, можно будет докрутить и тот же nginx (если он понадобится) и всё что нужно ещё.
Отвечая на вопрос - выбор инструмента это всегда вопрос предпочтений, но если небольшой проект может вырасти, то имеет смысл написать его, используя Tarantool.
На мой взгляд это зависит от задачи. Если у меня небольшой проект - всё, что я хочу сделать - это запустить ровно одну команду на сервере. И получать команды снаружи я хочу ровно в том виде, как мне удобно. Я не хочу настраивать nginx и всё остальное прочее.
Надеюсь я правильно понял вопрос.
Я не понял, что Вы спросили ). Можете спросить то же самое другими словами пожалуйста?
Прикольно. Я вот не знал про такую технологию у MS SQL сервера. Она вряд ли пригодится, но для общего развития интересно. У нас картинки хранятся на диске. В базе только их имена.