А ви теж помітили, що у гостя та ведучого однакові прізвища?

@dmitria8

26 күн бұрын

Мабуть співпадіння.

@ruslanchubatov

26 күн бұрын

Ідеальне співпадіння! Випуск - 🔥

@alexanderhetmanchuk3427

26 күн бұрын

енівей

@andrewdemchyshyn6599

25 күн бұрын

Світ тісний:)

@boatswain62

25 күн бұрын

Я помітив однакові фамілії і довго очікував цей випуск

1-2-3 Techno це ТОП! Підрубрика це ТОП в ТОПі! Коли слухаю ці подкасти, то ніби сиджу з другом за кавою і ми теревенимо про круті історії з життя та роботи 👍

@DOU_youtube

25 күн бұрын

Такий самий вайб

Шкода що не зʼясували до кінця, в чому саме була проблема. Проте дякую за розповідь. Початок війни й таке - дуже високий стрес. А під час стресу приймати зважені рішення значно складніше. Ви мололець.

@VsevolodSolovyov

25 күн бұрын

Дякую :)

Дякую за розмову! цікаво було б ще більше само про Data Science .

третя історія в саме серденько. респект.

Завжди цікаво! Так тримати

топова рубрика 🔥 дуже цікаво, дякую

Побачив Олександра і Передивився то шедевральний відео з fwdays 2013 року. Цікавий момент, ще тоді Олександр сказав що не любить лапшинова бо той прихильник путіна (40+ хвилина). І за це респект :) Фейл гітлаба - це прям вже історія. Ще б розказав як ключі ссш від доу віддавали бо в країні було зле…. Дякую! Крутий контент! Продовжуйте

@asolovyov

25 күн бұрын

Ключі ссх від доу? Шо за тема?

@oleksandrholovko2794

25 күн бұрын

@@asolovyov в гуглі Что с главной страницей DOU?

Як завжди кайфонув від всіх кулсторі. Хоч якась розпайка посеред всратійшого робочого циклу

Соловйови, запускайте власний подкаст. Дуже круто вийшло

@DOU_youtube

13 күн бұрын

"Солов'їною про IT"?

36:12 не згоден в ведучим, а навпаки з гостем. довгі транзації це гемор в будьякій скбд, особливо важко в locker (не mvcc як postgresql), але якщо це жива людина що випадково забула закомітити, це завжди така проблема. в принципі в pci-dss для живих людей є вимога щоб строк сесій живих людей які нічого не роблять обмежувати в часі до 15 хвилин. але не всі скбд це вміють, можна зовнішніми скриптами-ватчдогами що ходять перевіряють-кіляють, але це з'являється після того як знайшли причину - незрозумілу помилку, що залишає за собою сесії з відкритими транзакціями, або просто нормальні але довгі і термнійнути їх це прям зараз необхідний подорожник. але для постгреса я використовую patroni (primary-secondary реплікація), і для такого сетапу має сенс прокся яка буде перекидувати конекти на примарі-ноду. я використовую хапроксі, і там є дефолтне налаштування скільки tcp-сессія буде жити якщо по ній не бігають дані, timeout server, timeout client, наприклад 30хв, для oltp це достатньо. щодо обмеження взагалі до бд з "персональних ноутбуків", це вже не про те, це про безпосередньо інформаційну безпеку.

Здається я навіть пам'ятаю той стрім Гітлаба😅

зайти з CLI і почати транзакцію (ручками, не скрипт )на прод бд ??? Це на якому році проекту це трапилось?

Може на це питання відповідь буде далі, але завжди цікаво як люди/компанії прийшли саме до такої моделі бізнесу - чому саме грантові агенства, а не умовні VC? Як відбувся перший контакт з таким агенством

@VsevolodSolovyov

26 күн бұрын

Дуже гарне питання! В відео відповіді нема, хоча варто було б його обговорити. Про таку нішу майже неможливо дізнатись, якщо ти не в темі. А якщо ти розробник - то ти не темі 98-99% можливих B2B ніш. Як можна легко здогадатись, то початкова ідея бізнесу не моя. Мої два кофаундера - професори фізики (темна матерія, CERN, оце все), пишуть статті, отримують гранти, бувають panel member'ами в грантових агентствах, тощо. Перший контакт з таким агентством - на особистих зв'язках, якщо я правильно пам'ятаю, то на якійсь науковій конференції.

@antonpopov3127

26 күн бұрын

​@@VsevolodSolovyov А де ти познайомився з ко-фаундерами?

@VsevolodSolovyov

26 күн бұрын

​@@antonpopov3127 На роботі, лол. У мене немає якогось супер-перевіреного рецепту, як шукати кофаундерів у якихось цікавих нішах, нажаль. Вважаю, що нам просто пощастило. Але як завжди, щастить більш підготовленим людям, щоб був більший шанс такого "пощастило" - варто мати великий нетворк

@hash510

26 күн бұрын

подивіться на who's co-founder... І все зрозумієте

@VsevolodSolovyov

25 күн бұрын

@@antonpopov3127 на роботі, за пару років до. У мене нема якогось перевіреного надійного підходу, де знаходити класних кофаундерів.

56:36 доречі правда) треба перевірити s3 бекапи :-D

А контакти з приводу мілтек - до кого постучатись?

11:25 коли кажуть маленькі сервачки це про джаву та її модель heap, якщо heap меньше 32 гб, то можливо використовувати compressed-покажчики, і це може суттєво зекономити пам'яті. А щойно зробити більше 32гб памя'ті, то стає гірше,... Збільшуємо, і десь на рівні гігабайт 45-50, виходить на рівень 32 з компрессед опс. Але ж є зворотний бік, чим більше шкаф тім він гучніше падає

@ArtemMelanich

26 күн бұрын

Пробував гратися з цим.. різниця не така велика, може пару Гб.. принаймні на наших данних

@VsevolodSolovyov

26 күн бұрын

Так, точно, це теж тоді в 2020-му був аргумент за сервачки поменше.

не економте на девопсах і буде вам еластік працювати. для апдейт поля використовуте скріпти. еластік не зберігає старі документа (може тримати деяке сміття на видалення щоб потім підчистити автоматично).

@VsevolodSolovyov

26 күн бұрын

Прям зараз в одному з індексів: docs: 165,437,198 (617,527,759). 165 * 3 (бо три копії) = 495 мільйонів. Ще 120 мільйонів - це "деяке сміття"? Скрипт для апдейта одного поля допомогає так само. Так, можна не слати весь документ. Ні, це не допомагає, і еластік буде реіндексувати весь документ, це і в документації написано.

@Roman-sj1bj

26 күн бұрын

@@VsevolodSolovyov elasticsearch- partial update. по кількості документів якщо _cluster/stats не збігається з потріьбним тотало документів = delayed refresh, deleted documents, shard allocation or index errors. в нас в еластіку 5 млрд документів. ми б давно б вилетіли при такі поведінці.

@MiiDosvid

20 күн бұрын

тут суть не в эластике а в системе и очень сильно в бажном железе

@MiiDosvid

20 күн бұрын

​@@VsevolodSolovyov150м логов в день.

@MiiDosvid

20 күн бұрын

​@@VsevolodSolovyov сколько м записей не решает. решает оптимизация запроса, уменьшение внутреннего паразитного трафика, и качественное шардирование. но вот так спорить это как на свечку пукать. если есть трабла выложи архитектуру с конфигами, типовые запросы и прочее и тогда можно будет предметно обсудить. без этого это "у меня них не работает", "а на мое компе все работает". но вот с хецнера однозначно рекомендую сваливать и делать бекапы вне хецнера хоть на локалку(я так когда то спас всю компанию)

Коли CTO сам займається серверами, то це вирок Наймайте девопсів, читайте документацію та вмикайте моніторінг Про повреждение данные от неисправной сетевой карты это какой-то фейк Сетевая карта всегда одни и те же поля коверкала - ну это уже как байка Опять же, нужно мониторить сервера, нанимать девопсов То что верхний уровень начинает колбасить когда неисправен нижний это нормально. Это и есть сигнал к тому что что-то не так Судя по вашим рассказам вы что-то делаете с эластиком, а потом не понимаете почему и что происходит Т.е. вы не читаете документацию, логи, не делаете мониторинг Сделайте тег "1 апреля"

@VsevolodSolovyov

25 күн бұрын

Ви десь почули, що я сам займаюсь серверами? Я навіть там кажу прямим текстом «не люблю це робити», в контексті того, що людина, яка займається серверами, на той момент була без звʼязку. Мережева карта не портила одні і ті самі поля, це теж ви додумали. Що відбувається з еластіком я зазвичай чудово розумію. Змоги розбиратись в причинах проблеми саме 24 лютого 2022 року в мене не було.

а як же ті адміни, що перевіряють що бекапи розгортаються?)

перепрошую за питання не по темі, але ось цю чорочку з хвилями - то де таку можна придбати? Може хтось знає.

@asolovyov

26 күн бұрын

Чорочку?

@VsevolodSolovyov

26 күн бұрын

З посиланням ютуб заблочить комент, тому йдіть на yiume крапка ком, і там чоловічі гавайські сорочки, "japanese ukiyo-e".

@VsevolodSolovyov

25 күн бұрын

Yiume крапочка ком.

@stanislavstashchuk711

13 күн бұрын

@@VsevolodSolovyov Оу! Дякую!

@stanislavstashchuk711

13 күн бұрын

@@asolovyov Хтось стукає. То напевно мовний патруль. Краще не буду відчиняти.

Немного не понятно раскрыты проблемы эластика. 1. Название подкаста - Эластик не надежная скотина. Насколько я понял из разговора, когда поменяли машины на другие с ECC памятью, все стало работать норм. Так может это не Эластик скотина а старые инстансы?) По ECC памяти, насколько я вычитал, ещё в 2013 у aws все было на ECC так как это необходимость. Никогда не работал с Hetzner, но это немного удивило. 2. По поводу пересоздания индекса. Эластик не транзакционная база, она не может быть source of truth. Возможность пересоздания индекса без даунтайма это там must have по моему) Скорость создания индекса часто можно оптимизировать - сделать меньше шарды, поиграться с parallelism/batch size и тд. По другому писать индексы чтоб вместо одного индекса на терабайт было несколько по годам или авторам. 3. Как это удалить весь шард? Сколько было реплик шарда, все реплики погибли что-ли которые были на разных инстансах?) Было ли настроено snapshot lifecycle policy? 4. Segments merging logic довольно неплохо работает. Оно старается держать количество marked as deleted документов до 30% и периодически их чистит полностью. Падение производительности я замечал когда полностью перезаписываем 100% документов в эластике. В этой ситуации конечно раз в неделю пересоздаем индекс заново. Все это без даунтайма, просто переключаем алиас на новый индекс. Этот индекс специально разделён на два (hot и cold) и пересоздание занимает 30 мин. 5. По добавлению инстансов в кластер. Всегда можно сделать blue-green деплой и просто покопировать шарды в новый кластер) Так может даже правильнее с прод релизом где постоянно большая нагрузка. 6. Честно говоря, так и не понятно почему переезжают на Vespa. Всеволод сказал что последние 2 года все работает норм на эластике. Александр сказал что пока не делал полноценные прод тесты с Vespa. Отсутствие шардов в Vespa это ж может быть и минус. Если например в индексе эластика 2 миллиарда документов и 20 шардов, там можно заюзать роутинг который пойдёт в конкретный шард и не будет искать среди 2 миллиардов доков. Я про Vespa ниче не знаю, но интересно как это реализовано там) Было бы очень интересно послушать про ваши прод use cases где Vespa работает лучше. Время поиска для разных типов кверей, cpu/memory utilization дата нод, время индексирования, падение производительности при увеличении updated documents. Не у конечно для полноты картины, было б цікаво добавить деталей про текущий эластик - размер индексов, количество шардов и документов и тд) Так было бы больше понятно почему эластик все-таки скотина)

@VsevolodSolovyov

23 күн бұрын

1. Назву для випуску вибирають продюсери, нічого сказати не можу. У Хецнера серваки є з ECC, є без, як бажаєш. Це bare metal, в їхньому клауді все ECC. 2. Це ж не логи, мені індекси по рокам не допоможуть. Більшість запитів на пошук йде без обмеження на роки, а якщо вони і є - то це типу "останні 10-15 років". Наскільки зручно працювати, коли треба один запит слати в кілька індексів, і потім об'єднувати результати? Це точно не той шлях, який я буду розглядати першим, другим чи п'ятим. По авторам це просто неможливо зробити, у наукової статті не один автор. Можуть бути і сотні, і тисячі. 3. Якщо чесно, я не пам'ятаю точно, який саме API виклик тоді допоміг. Я зараз полистав їх API хвилин п'ятнадцать, і можливо це був неочікуваний результат викликів cluster reroute. Три копії даних. Поки листав доки, згадав, що деякі репліки шардів випадали в UNASSIGNED, і можливо це була комбінація випадіння в unassigned і того, що одна з "живих" копій згнила. Супер-детального постмортему з усіма деталями на початку війни не робив, вибачайте. Lifecycle policy не було. 4. Так, звісно, перестворення нового індексу це переключення аліасу без даунтайму. Для основного індексу я навіть з БД всі свої дані не витягну за півгодини, вже не кажучи про те, щоб будь-який індекс встиг за цей час побудуватись, заздрю вашим півгодинам. 6. Взагалі не планував нічого про Веспу казати, тут ніяких веселих історій немає. Переїжджаємо по причинам, які не пов'язані з надійністю чи операційною складністю еластіка. У веспи дуже класна підтримка векторних полів, запитів, комбінація цього зі звичайним full-text пошуком, фільтрами, тощо. Це важливо для мого продукту, дозволяє зручно зробити те, що іншими способами незручно, дає калічні результати, або дуже довго працює. У восьмому еластіку теж з'явилась базова підтримка векторів, але порівняно з веспою воно прям базове. Всі інші речі - приємні бонуси. Про роутинг, який не буде ходити в інші шарди - як я вже сказав, це не мій випадок. 7. У мене є наполовину написаний пост про те, як ми переїжджаємо з еластіка на веспу, але не схоже, щоб я його дописав найближчим часом. Розмір основного індексу (статті) в еластіку десять терабайт, 165 мільйонів документів (з копіями та оверхедом видалених - 620 млн).

Всмисле не треба глубоко ниряти? Тут ваш колега топ контент на 5+ годин робить, а ви шо :)

@asolovyov

26 күн бұрын

Колега дуже сміливий, а ми, бач, стараємося попасти в рамки фільмів 90-х 🤣

Проблема была в том что это хецнер на котором стабильно проебы с железом. У нас как то в один день ушел весь архивный кластер из 6 распределенных машин. Оцените вероятность такого чудесного события. а то что пропадал коннект тоже стандартная тема их глючных свитчей. Даже если в стойке одной будут стоять есть не малые риски все просрать. Там хоть и дешего, но общий урон от такого гавностроя и оплата людей для его фикса не стоит всего этого. Посему хецнер больше никогда ни для чего не юзаю. Лучше переплатит парк баксов чем схватить инфаркт в 30 лет. А эластик серч хоть и не самая стабильная тема иза Явы, но все же вполне ок решение и может обрабатывать терабайты инфы при правельной настройке как софта так и железа.

6-ти годинний бекап був зроблений ад-хок розробником для своїх пропріентарних потреб, і там було не все

@asolovyov

26 күн бұрын

Хм, але ж він просто LVM склонував, як може бути не все?

@OlegMarchuk

26 күн бұрын

@@asolovyov Так а інфра ж не з одного LVM мабуть. І він міг там щось нахерячити в скопійованій. Короче, це нормально довіряти більше тому "бекапу", який автоматизований

@asolovyov

26 күн бұрын

@@OlegMarchuk згоден, просто що їх пост цей момент проскакує, а я за давністю років дещо подробиці з інших місць підзабув вже

Цікаво.