Спасибо, что поделились интересным опытом. Просто интересно - а для чего могут быть нужны такие большие таблицы без первичного ключа? Это исторические данные какие-то?
Решение о сжатии не принимается "на лету". Решение о сжатии (жать или не жать и чем) принимается на этапе построения архитектуры приложения на основании сведений о среднестатистическом характере входных данных.
Прикольная идея - динамическая архитектура сжатия, если я правильно понял. Уверен, мои коллеги оценят. Мне с одной стороны нравится, но с другой же - не хотелось бы видеть такой модуль на своих проектах. Объясню почему.
Мне нужно будет оборудовать кластер под все три модели. Выделить ресурсы и так далее. А что, если модуль будет всегда выбирать только один вариант архитектуры? Что будет происходить при переключении между моделями? А нужно ли этот процесс мониторить?
С другой стороны, если я могу назвать коэффициенты, я тогда могу сразу определить нужную из трёх архитектуру. Я могу контролировать число экземпляров кластера и их роли. Мне легче один раз задать конфигурацию под нужную задачу. Я хочу простоты. Простота - это надёжность.
Спасибо за вопрос. Речь, видимо, про BSON. Давайте представим два случая. В первом случае мы просто сжимаем строку. Во втором случае мы преобразуем JSON в BSON и потом сжимаем. Дело в том, что и в первом и во втором случае получится плюс-минус такой же результат. Во втором случае просто степень сжатия будет меньше.
Простите, а вам какая религия не позволяет использовать что-то, кроме PostgreSQL? Из вашего второго примера я не увидел, что оно быстрое. Из статьи понятно, что оно отзывается за несколько миллисекунд, а какую нагрузку может выдерживать - непонятно. Автор же показал конкретный работающий стенд.
Нельзя сказать, что Tarantool прям необходим на небольшом проекте - серверную часть можно написать на чём угодно.
Вот Вы говорите "классический вариант", а я не знаю точно, что Вы имеете ввиду. Есть где-то руководство, где написано, как делать классический вариант? Чем классический вариант лучше или предпочтительнее остальных?
Тем не менее, Tarantool удобен - что бы реализовать какой-то концепт не нужно много кода. Он даёт большой потенциал роста - если проект вырастет, будет несложно его масштабировать. Впоследствии, можно будет докрутить и тот же nginx (если он понадобится) и всё что нужно ещё.
Отвечая на вопрос - выбор инструмента это всегда вопрос предпочтений, но если небольшой проект может вырасти, то имеет смысл написать его, используя Tarantool.
На мой взгляд это зависит от задачи. Если у меня небольшой проект - всё, что я хочу сделать - это запустить ровно одну команду на сервере. И получать команды снаружи я хочу ровно в том виде, как мне удобно. Я не хочу настраивать nginx и всё остальное прочее.
Прикольно. Я вот не знал про такую технологию у MS SQL сервера. Она вряд ли пригодится, но для общего развития интересно. У нас картинки хранятся на диске. В базе только их имена.
Интересно кем считается? Индивидуумами вроде того учителя, у которого в голове намешано не пойми что? Я про типа из штатов, который повешал в классе радужный флаг рядом с чучхе.
К марксизму явно сильно притянуто. Описываемое течение является прямым следствием плюрализма мнений. Это скорее "социальный либерализм".
А я вообще не понимаю, что принципиально нового и при этом полезного произошло в винде после XP. Ну ладно, вроде бы как 7-ку полностью переписали и она стала побыстрее и надёжнее. Ок. Всё, что происходило дальше - на мой взгляд лишено пользы для среднестатистического пользователя. Я к примеру, вообще не знаю чем 7-ка, например, отличается от 10-ки. Ну, понятно, кроме расположения кнопок и менюшек.
Отличия есть в оплате - вангую, что появится подписка на ОС. А поскольку в ней ничего не меняется, а ежегодно платить ни за что я не хочу (то что у меня уже есть, я за это уже несколько раз заплатил), то я впервые попробовал установить и попробовать Linux. И вот я уже несколько дней в нём работаю и мне всё нравится. А поставился Linux вообще мгновенно, я даже офигеть не успел. Просто включил и начал работать.
В дополнение к статье рекомендую очень годную лекцию Алексея Сафронова (на мой взгляд в ней намного больше интересной информации): https://youtu.be/MtgXRgHJoTM
У Дракон-а и BPMN действительно разные сферы применения. Дракон, если я правильно понял, ориентирован на создание небольших отказоустойчивых алгоритмов. Если алгоритм будет большим, то вряд ли сыграют визуальные преимущества, для проверки моих слов — откройте любую программу в IDA Pro.
… но делу не помогает
Не могу согласиться. Ещё как помогает. BPMN ориентирован на описание бизнес-процессов. Для решения задач автоматизации, при первоначальном отсутствии этих схем, они зачастую рисуются со слов сотрудников на местах. Для обработки таких схем используется разнообразное ПО, например ARIS. Если схемы уже есть — это хорошо. Это хорошо, даже если они нарисованы не по стандарту. Общие схемы хорошо дополняют самодокументируемый код. Их задача для разработчика — дать контекст.
Они дают высокому начальству иллюзию контроля
Вы думаете топы их куда-то в папку складывают и радуются? Это вообще не так работает. BPMN-схемы используются для проработки какого-то проекта. Иногда и топы могут заинтересоваться какой-то деталью и потыкать пальцем в схему, позадавать вопросы (например спросить что-то такое: мы это везём отсюда сюда, а вот этот ждёт, а потом сюда, мы можем это сразу везти сюда?). Никогда не встречал ситуации, когда от стандарта BPMN требовалось бы что-то большее, чем то, что в нём уже есть.
Вообще, работая в ритейле, испытываю смешанные чувства по поводу спора о стрелочках. Для меня радость, если в компании есть документация, а в ней есть статья на нужную тему, а в ней есть фотография доски с хоть каким-то объяснением происходящего, пусть даже это объяснение нарисовано поверх прежней схемы.
У диаграммы деятельности более широкое применение. Ей можно описывать параллельные процессы и их взаимодействие. Круглишки, в которые сходятся стрелки, имеют возможность размещать иконки AND, OR, XOR.
На мой взгляд это всё вкусовщина. Сам последнее время использую то, что дают в markdown. Если нужно нарисовать бизнес-процесс, то мне больше нравится стандарт BPMN 2.0.
Замечу также, что в предлагаемом стандарте Дракон есть прикольные идеи (например отсылка к вероятностям срабатывания или "нормальности" в условных переходах), но они неочевидны после прочтения 70 страничного вложения. Стоило, на мой взгляд, в этой статье перечислить фичи и как ими пользоваться.
Сравнить таблицу и с её репликой
Спасибо, что поделились интересным опытом. Просто интересно - а для чего могут быть нужны такие большие таблицы без первичного ключа? Это исторические данные какие-то?
Как мы сжимаем данные в больших проектах
Решение о сжатии не принимается "на лету". Решение о сжатии (жать или не жать и чем) принимается на этапе построения архитектуры приложения на основании сведений о среднестатистическом характере входных данных.
Как мы сжимаем данные в больших проектах
Мне тут коллеги подсказали, что внутри Tarantool так и хранит - в бинарном формате msgpack.
Как мы сжимаем данные в больших проектах
Прикольная идея - динамическая архитектура сжатия, если я правильно понял. Уверен, мои коллеги оценят. Мне с одной стороны нравится, но с другой же - не хотелось бы видеть такой модуль на своих проектах. Объясню почему.
Мне нужно будет оборудовать кластер под все три модели. Выделить ресурсы и так далее. А что, если модуль будет всегда выбирать только один вариант архитектуры? Что будет происходить при переключении между моделями? А нужно ли этот процесс мониторить?
С другой стороны, если я могу назвать коэффициенты, я тогда могу сразу определить нужную из трёх архитектуру. Я могу контролировать число экземпляров кластера и их роли. Мне легче один раз задать конфигурацию под нужную задачу. Я хочу простоты. Простота - это надёжность.
Спасибо, что поделились мыслью.
Как мы сжимаем данные в больших проектах
Спасибо за вопрос. Речь, видимо, про BSON.
Давайте представим два случая. В первом случае мы просто сжимаем строку. Во втором случае мы преобразуем JSON в BSON и потом сжимаем. Дело в том, что и в первом и во втором случае получится плюс-минус такой же результат. Во втором случае просто степень сжатия будет меньше.
Хранение графов в Tarantool: реальность или миф
Простите, а вам какая религия не позволяет использовать что-то, кроме PostgreSQL? Из вашего второго примера я не увидел, что оно быстрое. Из статьи понятно, что оно отзывается за несколько миллисекунд, а какую нагрузку может выдерживать - непонятно. Автор же показал конкретный работающий стенд.
Модуль ACME-клиента для Tarantool
Нельзя сказать, что Tarantool прям необходим на небольшом проекте - серверную часть можно написать на чём угодно.
Вот Вы говорите "классический вариант", а я не знаю точно, что Вы имеете ввиду. Есть где-то руководство, где написано, как делать классический вариант? Чем классический вариант лучше или предпочтительнее остальных?
Тем не менее, Tarantool удобен - что бы реализовать какой-то концепт не нужно много кода. Он даёт большой потенциал роста - если проект вырастет, будет несложно его масштабировать. Впоследствии, можно будет докрутить и тот же nginx (если он понадобится) и всё что нужно ещё.
Отвечая на вопрос - выбор инструмента это всегда вопрос предпочтений, но если небольшой проект может вырасти, то имеет смысл написать его, используя Tarantool.
Модуль ACME-клиента для Tarantool
На мой взгляд это зависит от задачи. Если у меня небольшой проект - всё, что я хочу сделать - это запустить ровно одну команду на сервере. И получать команды снаружи я хочу ровно в том виде, как мне удобно. Я не хочу настраивать nginx и всё остальное прочее.
Надеюсь я правильно понял вопрос.
Модуль ACME-клиента для Tarantool
Я не понял, что Вы спросили ). Можете спросить то же самое другими словами пожалуйста?
Хранение изображений сайта в БД
Прикольно. Я вот не знал про такую технологию у MS SQL сервера. Она вряд ли пригодится, но для общего развития интересно. У нас картинки хранятся на диске. В базе только их имена.
Netflix: уход подписчиков, растущая конкуренция и попытка войти на рынок видеоигр
Интересно кем считается? Индивидуумами вроде того учителя, у которого в голове намешано не пойми что? Я про типа из штатов, который повешал в классе радужный флаг рядом с чучхе.
К марксизму явно сильно притянуто. Описываемое течение является прямым следствием плюрализма мнений. Это скорее "социальный либерализм".
Windows 11 движется не в том направлении…
Я для себя ответил так: Ubuntu, JetBrains
Windows 11 движется не в том направлении…
А я вообще не понимаю, что принципиально нового и при этом полезного произошло в винде после XP. Ну ладно, вроде бы как 7-ку полностью переписали и она стала побыстрее и надёжнее. Ок. Всё, что происходило дальше - на мой взгляд лишено пользы для среднестатистического пользователя. Я к примеру, вообще не знаю чем 7-ка, например, отличается от 10-ки. Ну, понятно, кроме расположения кнопок и менюшек.
Отличия есть в оплате - вангую, что появится подписка на ОС. А поскольку в ней ничего не меняется, а ежегодно платить ни за что я не хочу (то что у меня уже есть, я за это уже несколько раз заплатил), то я впервые попробовал установить и попробовать Linux. И вот я уже несколько дней в нём работаю и мне всё нравится. А поставился Linux вообще мгновенно, я даже офигеть не успел. Просто включил и начал работать.
Последние новости о сделке по покупке TikTok: чего хотят покупатели, влияние властей Китая и США
Тема акций не раскрыта — где можно купить акции ByteDance?
Вера Глушкова: «Вирус кибернетики витал над городом Киевом»
В дополнение к статье рекомендую очень годную лекцию Алексея Сафронова (на мой взгляд в ней намного больше интересной информации):
https://youtu.be/MtgXRgHJoTM
Нужен ли Вооруженным Силам России и другим структурам Министерства обороны РФ стандарт для описания алгоритмов?
Из предложенного описания стандарта это неочевидно.
Можете показать на примере?
Нужен ли Вооруженным Силам России и другим структурам Министерства обороны РФ стандарт для описания алгоритмов?
У Дракон-а и BPMN действительно разные сферы применения. Дракон, если я правильно понял, ориентирован на создание небольших отказоустойчивых алгоритмов. Если алгоритм будет большим, то вряд ли сыграют визуальные преимущества, для проверки моих слов — откройте любую программу в IDA Pro.
Не могу согласиться. Ещё как помогает. BPMN ориентирован на описание бизнес-процессов. Для решения задач автоматизации, при первоначальном отсутствии этих схем, они зачастую рисуются со слов сотрудников на местах. Для обработки таких схем используется разнообразное ПО, например ARIS. Если схемы уже есть — это хорошо. Это хорошо, даже если они нарисованы не по стандарту. Общие схемы хорошо дополняют самодокументируемый код. Их задача для разработчика — дать контекст.
Вы думаете топы их куда-то в папку складывают и радуются? Это вообще не так работает. BPMN-схемы используются для проработки какого-то проекта. Иногда и топы могут заинтересоваться какой-то деталью и потыкать пальцем в схему, позадавать вопросы (например спросить что-то такое: мы это везём отсюда сюда, а вот этот ждёт, а потом сюда, мы можем это сразу везти сюда?). Никогда не встречал ситуации, когда от стандарта BPMN требовалось бы что-то большее, чем то, что в нём уже есть.
Boston Dynamics: магия или имитация?
"Пруфы искать лень"
Так не пойдёт. Вы сначала пруфы найдите, а потом минусите автора.
Нужен ли Вооруженным Силам России и другим структурам Министерства обороны РФ стандарт для описания алгоритмов?
Вообще, работая в ритейле, испытываю смешанные чувства по поводу спора о стрелочках. Для меня радость, если в компании есть документация, а в ней есть статья на нужную тему, а в ней есть фотография доски с хоть каким-то объяснением происходящего, пусть даже это объяснение нарисовано поверх прежней схемы.
Нужен ли Вооруженным Силам России и другим структурам Министерства обороны РФ стандарт для описания алгоритмов?
У диаграммы деятельности более широкое применение. Ей можно описывать параллельные процессы и их взаимодействие. Круглишки, в которые сходятся стрелки, имеют возможность размещать иконки AND, OR, XOR.
На мой взгляд это всё вкусовщина. Сам последнее время использую то, что дают в markdown. Если нужно нарисовать бизнес-процесс, то мне больше нравится стандарт BPMN 2.0.
Замечу также, что в предлагаемом стандарте Дракон есть прикольные идеи (например отсылка к вероятностям срабатывания или "нормальности" в условных переходах), но они неочевидны после прочтения 70 страничного вложения. Стоило, на мой взгляд, в этой статье перечислить фичи и как ими пользоваться.