Cʕ
это пол или потолок? я просто ламер...
это стена😄
Size: a a a
2020 October 13
2020 October 14
J
Это пиздец!
2020 October 19
I
It’s a function that deletes the local database and creates all the required tables from scratch. This evening, whilst doing some late evening coding, the function connected to the production database and wiped it. Why? This is something we’re still trying to figure out.
2020 October 20
J
Это часом не тот чувак который на реддит писал когда-то что в первый рабочий день дропнул базу прода?))
S
Вряд ли
Cʕ
> after a couple of glasses of red wineНе учатся ничему некоторые и учиться не хотят
DB
> after a couple of glasses of red wineНе учатся ничему некоторые и учиться не хотят
обязательный фильтр на наличие алкоголя в крови, капчу? :)
Cʕ
Dmitrii Barsukov
обязательный фильтр на наличие алкоголя в крови, капчу? :)
На входе в офис, детектор алкоголя
Cʕ
А если из дома работаешь, то тут сложна
DB
На входе в офис, детектор алкоголя
VPN не подключается без USB детектора
DB
На входе в офис, детектор алкоголя
еще общага нас учила, что заходят все трезвые, основное действие всегда внутри происходит
AT
Там же вроде один человек и его пет-прожект
AT
Странно винить его в том, что программирует с винишком дома
2020 October 21
I
он же писал что дело не в винишке было, а в том что
- сначала он затёр прод.бд через скрипт для дропа тестовой базы. Это фейл за который его никто и не винит, случается такое.
- а потом не осилил сделать восстановление бд на последний момент времени и взял ночной бекап, потому что не прочитал справку к managed databases у DO, что там можно применять бинарные логи. Вот это лол по мне.
- сначала он затёр прод.бд через скрипт для дропа тестовой базы. Это фейл за который его никто и не винит, случается такое.
- а потом не осилил сделать восстановление бд на последний момент времени и взял ночной бекап, потому что не прочитал справку к managed databases у DO, что там можно применять бинарные логи. Вот это лол по мне.
2020 October 22
S
On October 21, 2020, at approximately 14:11 UTC AS203 started to announce 158 prefixes that almost immediately created more than 1100 conflicts for a 1000+ of advertised prefixes. This incident, which has not stopped yet while we are writing this particular report, affected 31 ISPs in 19 countries, including such players as AS9198 - KAZTELECOM-AS, AS35415 - WEBZILLA, AS7979 - SERVERS-COM and many more.
https://radar.qrator.net/blog/lumen-aka-centurylink-generating-routing-incidents
https://radar.qrator.net/blog/lumen-aka-centurylink-generating-routing-incidents
VR
Привет.
А есть тут кто-нибудь кто разбирается в базах для быстрого поиска.
Есть вопосик что выбрать кроме эластика.
Потому как требование хранить данные всех пользователей отдельно друг от друга.
А эластик не любит больше 600 индексов на ноду.
А есть тут кто-нибудь кто разбирается в базах для быстрого поиска.
Есть вопосик что выбрать кроме эластика.
Потому как требование хранить данные всех пользователей отдельно друг от друга.
А эластик не любит больше 600 индексов на ноду.
S
хм,
вы точно уверены что вам надо раздельно именно ХРАНИТЬ?
может вам достаточно контролировать доступ?
выглядит так что вам нужна БД с полнотекстовым и фасетным поиском, но при этом чтобы была rows security ?
что мешает client_id в elastic хранить отдельным полем и проставлять его как фильтр при всех остальных запросах?
вы даете прямой доступ к elasticsearch клиентам?
вы точно уверены что вам надо раздельно именно ХРАНИТЬ?
может вам достаточно контролировать доступ?
выглядит так что вам нужна БД с полнотекстовым и фасетным поиском, но при этом чтобы была rows security ?
что мешает client_id в elastic хранить отдельным полем и проставлять его как фильтр при всех остальных запросах?
вы даете прямой доступ к elasticsearch клиентам?
VR
хм,
вы точно уверены что вам надо раздельно именно ХРАНИТЬ?
может вам достаточно контролировать доступ?
выглядит так что вам нужна БД с полнотекстовым и фасетным поиском, но при этом чтобы была rows security ?
что мешает client_id в elastic хранить отдельным полем и проставлять его как фильтр при всех остальных запросах?
вы даете прямой доступ к elasticsearch клиентам?
вы точно уверены что вам надо раздельно именно ХРАНИТЬ?
может вам достаточно контролировать доступ?
выглядит так что вам нужна БД с полнотекстовым и фасетным поиском, но при этом чтобы была rows security ?
что мешает client_id в elastic хранить отдельным полем и проставлять его как фильтр при всех остальных запросах?
вы даете прямой доступ к elasticsearch клиентам?
Прямого доступа нет.
Но программисты не смогли ддоговориться с менеджментом.
Сами запизнули всё в эластик.
получилось 8к индексов по 300мб.
Всё сломалось пролежало сутки прибежали исказали надо что-то сделать.
Но структуру хранения поменять не можем потому что уже заанонсили и рассказали клиентам.
Но программисты не смогли ддоговориться с менеджментом.
Сами запизнули всё в эластик.
получилось 8к индексов по 300мб.
Всё сломалось пролежало сутки прибежали исказали надо что-то сделать.
Но структуру хранения поменять не можем потому что уже заанонсили и рассказали клиентам.
S
ну из модных альтернатив эластику
https://github.com/meilisearch/MeiliSearch
https://github.com/tantivy-search/tantivy
https://github.com/bayard-search/bayard
https://github.com/toshi-search/Toshi
все на rust
все быстрее elastic
но пока кластеризацией там не пахнет
https://github.com/meilisearch/MeiliSearch
https://github.com/tantivy-search/tantivy
https://github.com/bayard-search/bayard
https://github.com/toshi-search/Toshi
все на rust
все быстрее elastic
но пока кластеризацией там не пахнет
