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