// any request to "/search/*" endpoint will
// automatically receive an array with two book objects
cy.intercept('/search/*', [{ item: 'Book 1' }, { item: 'Book 2' }]).as(
'getSearch'
)
cy.get('[data-testid="autocomplete"]').type('Book')
// this yields us the interception cycle object
// which includes fields for the request and response
cy.wait('@getSearch').its('request.url').should('include', '/search?query=Book')
cy.get('[data-testid="results"]')
.should('contain', 'Book 1')
.and('contain', 'Book 2')
Результаты этих тестов нужно было где-то хранить. Для такой задачи решили использовать Allure.
В cypress хранение "из коробки", при этом можно повторно "проигрывать" тесты, Test Replay
Для уменьшения негативного эффекта достаточно просто поменять местами поля в структуре: так, чтобы маленькие однобайтовые поля были в начале, а большой, четырехбайтный int — в самом конце:
Лучше делать наборот - маленькие в конце, иначе может случиться padding:
Data alignment is the aligning of elements according to their natural alignment. To ensure natural alignment, it may be necessary to insert some padding between structure elements or after the last element of a structure. For example, on a 32-bit machine, a data structure containing a 16-bit value followed by a 32-bit value could have 16 bits of padding between the 16-bit value and the 32-bit value to align the 32-bit value on a 32-bit boundary. Alternatively, one can pack the structure, omitting the padding, which may lead to slower access, but uses three quarters as much memory.
Формулу возведения в степень вы, я полагаю, взяли из схемы Бернулли
Будем так говорить, я её на листочке вывел по ходу дела, собственно, весь вывод повторён в моём комментарии.
Например, после прочтения слова FUCK, следующим словом для проверки будет UCK* - т.е. 100% не FUCK. Вероятность следующего события зависит от предыдущего события.
Но это даже не важно, потому что вы, скорее всего, имели ввиду умножение на 17, а не возведение в 17-ю степень
Нет, именно возведение в степень. Вероятность выбросить решку пять раз подряд 1/2^5. Вероятность появления орла в серии = 1 - 1/2^5 = 0.96875.
это же подтверждает ваш ответ, не совпадающий с тем, что дала бы формула
Тут ситуация обоюдоострая, возможно, таки, неверна формула. "Нетрудно понять..." - это сильное утверждение, но необязательно верное. Хотелось бы разобраться.
вы складываете вероятности событий, которые пересекаются
Но я не складываю вероятности.
вы складываете вероятности событий, которые пересекаются.
Тогда бы получилось "больше". А у меня - "меньше".
Понятно, спасибо. Если можно, приведите примеры, для каких операций в avito используется описанный "асинхронный подход", а для каких этого недостаточно и приходится "синхронизировать".
Интересно, как при свободной смене сервера обеспечить Read-Your-Writes? Пишем в x=x+1 (=9+1=10 ) в SRV1, репликация асиннхронная(?), после записи SRV1 выпадает из сети, репликация не завершена. Идем на SRV2 и там читаем x==9.
Каждый пир пишет синхронно в локальную базу, и отложенно происходит синхронизация с другими пирами.
Это случай "Clients only talk to the same servers, instead of switching to new ones". В таком сценарии обеспечиваются уровни изоляции и согласованности, обозначенные синим и желтым цветами.
Конкретно с определением Snapshot дело обстоит так - можно обеспечить все требования кроме First-committer-wins. Это требование, в случае использования CRDTs, является излишним (так как нацелено на Lost Update, каковой невозможен с такими типами) тем не менее, оно есть в приводимых формулировках.
Можно как-то по другому назвать, например, Snapshot-CRDTs.
Это следующий этап, КМК. Сначала определяем понятие Consistency, а затем уже можно его связывать с другими, например с Availability и Partition tolerance.
Тут надо на архитектуру смотреть. Мы сейчас "пилим" вот такое:
База распределенная (две копии), репликация асимметрична и асинхронна.
Snapshot Isolation
На клонированной из облака копии Strong Partition Serializable для пишущих транзакций, Eventual Consistency для транзакций на чтение.
Total Available
В нашем случае нет (хотя, видимо, зависит от определений), в "облако" писать нельзя пока активен Local Box (aka Edge Node)
Causal Consistency, Strong Eventual Consistency
Пожалуй, но, в нашем случае, только с применением оргмер. Без них, например, можно получить split brain - в облаке отметить что Local Box "умер", соответственно, с облачной копией теперь можно работать, но и с Local Box технически можно продолжать работать, и тогда, конечно, настанет время удивительных чудес с перемещениями во времени.
А как же...
В cypress хранение "из коробки", при этом можно повторно "проигрывать" тесты, Test Replay
Неплохо👍
А если все ядра уже заняты полезной вычислительной работой, разве асинхронная обработка не повлияет на производительность?
Пожалуй. Это стоило бы осветить в статье, КМК.
Лучше делать наборот - маленькие в конце, иначе может случиться padding:
Будем так говорить, я её на листочке вывел по ходу дела, собственно, весь вывод повторён в моём комментарии.
Да, так и есть🔥🍺
Нет, именно возведение в степень. Вероятность выбросить решку пять раз подряд 1/2^5. Вероятность появления орла в серии = 1 - 1/2^5 = 0.96875.
Тут ситуация обоюдоострая, возможно, таки, неверна формула. "Нетрудно понять..." - это сильное утверждение, но необязательно верное. Хотелось бы разобраться.
Но я не складываю вероятности.
Тогда бы получилось "больше". А у меня - "меньше".
А в чём проблема, интересно, вот такого варианта.
В строке из 20 символов - 17 попыток набрать группу из 4 символов
В каждой попытке вероятность получить группу 1 / 26 ^ 4, не получить (1 - 1 / 26 ^ 4)
Не получить в 17 попытках: (1 - 1 / 26 ^ 4) ^ 17
Получить хотя бы в одной попытке = 1 - не получить ни в одной = 1 - (1 - 1 / 26 ^ 4) ^ 17 = 0.00003720042
Вольфрам даёт 0.0000372004271441587940142843061796238205490663502391574596846357
В облаке, что ли? Можете схемку набросать, допустим, тут https://mermaid.live?
Понятно, спасибо. Если можно, приведите примеры, для каких операций в avito используется описанный "асинхронный подход", а для каких этого недостаточно и приходится "синхронизировать".
А где предполагается хранить local-first базы для случая avito?
Можно подробнее, в каких ситуациях могут быть потеряны данные в такой архитектуре?
Подскажите, какое ПО используется для создания схем такого типа?
Ну т.е. клиент всегда пишет в одну базу, "Clients only talk to the same servers, instead of switching to new ones".
Как только он переключится возможна потеря уровня Read-Your-Writes.
У клиента для этого еще одна база должна быть и именно в нее он и должен всегда писать First.
Интересно, как при свободной смене сервера обеспечить Read-Your-Writes? Пишем в x=x+1 (=9+1=10 ) в SRV1, репликация асиннхронная(?), после записи SRV1 выпадает из сети, репликация не завершена. Идем на SRV2 и там читаем x==9.
Как избежать такой ситуации?
У Вас все-таки такая архитектура:
Это случай "Clients only talk to the same servers, instead of switching to new ones". В таком сценарии обеспечиваются уровни изоляции и согласованности, обозначенные синим и желтым цветами.
Конкретно с определением Snapshot дело обстоит так - можно обеспечить все требования кроме First-committer-wins. Это требование, в случае использования CRDTs, является излишним (так как нацелено на Lost Update, каковой невозможен с такими типами) тем не менее, оно есть в приводимых формулировках.
Можно как-то по другому назвать, например, Snapshot-CRDTs.
Согласно jepsen.io Cursor Stability и выше а также Snapshot Isolation и выше не могут быть Total Available.
Подозреваю, имеет место разница в формулировках либо какие-то особенности работы с данными, типа каждый пир только вставляет данные.
Это следующий этап, КМК. Сначала определяем понятие Consistency, а затем уже можно его связывать с другими, например с Availability и Partition tolerance.
Тут надо на архитектуру смотреть. Мы сейчас "пилим" вот такое:
База распределенная (две копии), репликация асимметрична и асинхронна.
На клонированной из облака копии Strong Partition Serializable для пишущих транзакций, Eventual Consistency для транзакций на чтение.
В нашем случае нет (хотя, видимо, зависит от определений), в "облако" писать нельзя пока активен Local Box (aka Edge Node)
Пожалуй, но, в нашем случае, только с применением оргмер. Без них, например, можно получить split brain - в облаке отметить что Local Box "умер", соответственно, с облачной копией теперь можно работать, но и с Local Box технически можно продолжать работать, и тогда, конечно, настанет время удивительных чудес с перемещениями во времени.