А индексы тоже сжимается или только данные в таблицах?
Ну и наверное есть повышенное требование на оперативную память, ведь поднять в память кусок таблицы и распаковать займёт теперь в 5 раз больше места, или это не так?
Как распаковка данных влияет на требования к cpu, теперь же кроме джойнов нужно ещё и распаковку выполнять, особенно сильно должно в много пользовательского системе влиять, делали ли такие замеры?
А отсюда как-то можно понять что это за коэффициенты k и g00 и какая у них размерность? Можно ли отсюда установить связь с гравитационной постоянной G?
А если со временем из-за излучения Хокинга масса дыры упадёт до того состояния, что дыра не может оставаться чёрной дырой, то дыра рванет и снова все вернётся и материя и информация?
Как будто не учтён ещё кейс, когда все ОК, но в момент финального ack все сломалось и сообщение ушло в retry. А затем при повторной обработке кто-то успешно купит две пиццы вместо одной :).
Нужно ещё видимо где-то хранить и проверять статус основного события, обработано оно или нет и проверять его перед обработкой.
Репликационный слот накладывает ограничение на перезапись wal. Т.е. пока данные из слота не прочитаны wal будет расти и при высокой нагрузке может очень быстро съесть все отведенное место на диске, с дальше сервер упадёт с ошибкой.
Даже если int занимает 4 байта, а UUID 16? Особенно в сложных системах, где много таблиц нормализованных и много связей между ними по идентификатора. Да ещё и с индексами по этим идентификаторам.
Тут накладные расходы на хранение идентификатором могут быть значительными, всегда ли оно того стоит?
В итоге, первый insert выполнится успешно, а второй — свалится с ошибкой вставки по уникальному ключу (если вы, конечно, создали для внешнего идентификатора уникальный индекс).
По идее если используется сиквенса или UUID для внешнего идентификатора, то не будет дубликатов по ключу, но будет две одинаковые записи с разными ключами.
UUID — это стандарт идентификации, используемый в создании программного обеспечения Основное назначение UUID — это позволить распределённым системам уникально идентифицировать информацию без центра координации.
Тут есть как плюсы так и минусы, поэтому всегда так делать не стоит, нужно оценивать ситуацию. Если объект в бд хранится и по полю с идентификатором есть кластеры индекс, то лучше использовать монотонно возрастающие идентификатор от сиквенса. Так при вставке не придётся постоянно пересортировывать таблицу в бд.
Также генерация UUID более затратна и если нужно для массовой операции сразу 1000 идентификатор сформировать, то это можно сделать только последовательно дернув 1000 раз функцию получения UUID, а у сиквенса можно сразу диапазон запросить за один вызов.
При таком подходе скорость роста размера БД в которой храняться события будет космической. А с ростом БД появится куча проблем с хранение резервных копий (диски может и не дорогие, но цена отличная от нуля), подъёмом дампа (в случае сбоя например), замедлением работы индексов если они есть. При этом написано, что удаление из БД не предусмотрено. Как тогда быть?
Полезно было бы, если этот подход к БД был применим. Особенно для операций сравнения строк или для like например. Чтобы слив базы не приводил к раскрытию информации, если у атакубщего нет доступа к ключу шифрования.
На рис 1.8 у вектора A-B нужно поменять направление, сейчас там вектор B-A.
коэффициент Отиаи - это по сути единица минус нормированное скалярное произведение сравниваемых векторов. Т.е. Чем более схожи вектора, тем ближе их нормированное скалярное произведение к 1, а коэффициент Отиаи соответственно к нулю. Т.е. формально коэффициент Отиаи показывает величину отличия, а не сходства двух векторов.
А индексы тоже сжимается или только данные в таблицах?
Ну и наверное есть повышенное требование на оперативную память, ведь поднять в память кусок таблицы и распаковать займёт теперь в 5 раз больше места, или это не так?
Как распаковка данных влияет на требования к cpu, теперь же кроме джойнов нужно ещё и распаковку выполнять, особенно сильно должно в много пользовательского системе влиять, делали ли такие замеры?
А отсюда как-то можно понять что это за коэффициенты k и g00 и какая у них размерность? Можно ли отсюда установить связь с гравитационной постоянной G?
А если со временем из-за излучения Хокинга масса дыры упадёт до того состояния, что дыра не может оставаться чёрной дырой, то дыра рванет и снова все вернётся и материя и информация?
Не очень понятно из предложенного кода, как учитывается вероятность перехода при генерации текста. По коду выходит, что все переходы равновероятны.
Вроде это из манифеста python третий пункт, он Guido van Rossum :)
если сервис C отвечает статусом
304 Not Modified, вернуть данные из кэша;А в чем преимущество такого подхода?
Ведь чтобы понять что ничего не поменялось, нужно дёрнуть сервис.
Ну и проще отдать ответ сервиса, чем с кешем что-то делать.
Часто на созвонах требуется чтобы была камера включена и видно лицо собеседника. А тут вместо лица очки будут.
Такое не всем подойдёт.
В дикой природе нет супер существа, которое может влияеть на всех. Там честная конкуренция отдельных индивидов или небольших групп. Разве не так?
А ещё можно было сжать эту строку. Судя по большому числу повторяющиеся символов был бы профит.
Как будто не учтён ещё кейс, когда все ОК, но в момент финального ack все сломалось и сообщение ушло в retry. А затем при повторной обработке кто-то успешно купит две пиццы вместо одной :).
Нужно ещё видимо где-то хранить и проверять статус основного события, обработано оно или нет и проверять его перед обработкой.
А если в процессе разработки многое меняется, то нужно постоянно актуализировать описание? Т.е. работаю в паре разработчик и аналитик всякий раз?
Репликационный слот накладывает ограничение на перезапись wal. Т.е. пока данные из слота не прочитаны wal будет расти и при высокой нагрузке может очень быстро съесть все отведенное место на диске, с дальше сервер упадёт с ошибкой.
Даже если int занимает 4 байта, а UUID 16? Особенно в сложных системах, где много таблиц нормализованных и много связей между ними по идентификатора. Да ещё и с индексами по этим идентификаторам.
Тут накладные расходы на хранение идентификатором могут быть значительными, всегда ли оно того стоит?
В итоге, первый insert выполнится успешно, а второй — свалится с ошибкой вставки по уникальному ключу (если вы, конечно, создали для внешнего идентификатора уникальный индекс).По идее если используется сиквенса или UUID для внешнего идентификатора, то не будет дубликатов по ключу, но будет две одинаковые записи с разными ключами.
UUID — это стандарт идентификации, используемый в создании программного обеспечения Основное назначение UUID — это позволить распределённым системам уникально идентифицировать информацию без центра координации.![]()
Тут есть как плюсы так и минусы, поэтому всегда так делать не стоит, нужно оценивать ситуацию. Если объект в бд хранится и по полю с идентификатором есть кластеры индекс, то лучше использовать монотонно возрастающие идентификатор от сиквенса. Так при вставке не придётся постоянно пересортировывать таблицу в бд.
Также генерация UUID более затратна и если нужно для массовой операции сразу 1000 идентификатор сформировать, то это можно сделать только последовательно дернув 1000 раз функцию получения UUID, а у сиквенса можно сразу диапазон запросить за один вызов.
При таком подходе скорость роста размера БД в которой храняться события будет космической. А с ростом БД появится куча проблем с хранение резервных копий (диски может и не дорогие, но цена отличная от нуля), подъёмом дампа (в случае сбоя например), замедлением работы индексов если они есть. При этом написано, что удаление из БД не предусмотрено. Как тогда быть?
Полезно было бы, если этот подход к БД был применим. Особенно для операций сравнения строк или для like например. Чтобы слив базы не приводил к раскрытию информации, если у атакубщего нет доступа к ключу шифрования.
Тут наверное можно ещё yield упомянуть.
Он тоже останавливает итерации цикла.
На рис 1.8 у вектора A-B нужно поменять направление, сейчас там вектор B-A.
коэффициент Отиаи - это по сути единица минус нормированное скалярное произведение сравниваемых векторов. Т.е. Чем более схожи вектора, тем ближе их нормированное скалярное произведение к 1, а коэффициент Отиаи соответственно к нулю. Т.е. формально коэффициент Отиаи показывает величину отличия, а не сходства двух векторов.
А что случиться если retry exchanbe не смог выгрузить сообщение с просроченные ttl в wild queue?