Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
Senior Solution Architect в EPAM
  • Як модернізувати Java легасі-код

    I feel your pain :). В мене був період в житті, коли я часто взаємодіяв з британськими оракловими «бородатими ДБА в светрах» :) Було декілька «цікавих історій», може колись зроблю допис з веселими байками, які зрозумілі тільки програмістам.

    Підтримали: Alex Fogol, Dmitry Bugay
  • Як модернізувати Java легасі-код

    А ще зазвичай фіг віддебажиш в нормальному дебагері і фіг відтестиш логіку юніттестами...

    Підтримали: Bot Bot, Dmitry Bugay
  • Використання транзакцій в реляційних базах даних: забезпечення надійності та цілісності

    І тут є декілька нюансів :)
    — Я б не сказав що у переважної більшості проектів є централізований кеш. Так, це часте явище, але в багатьої проектах він не потрібен з різних причин.
    — Досить часто треба щось залочити тільки на час виконання транзакції. Тобто ви і так знаєте, що будете тримати конекшен. Нащо тоді ходити в сторонню систему?
    — База сама менеджить життєвий цикл локів, які вона надає. Якщо лок прив’язаний до сесії або транзакції — база сама його зніме, коли відповідний ресурс закінчить своє існування. А для зовнішніх локів треба самому менеджити їх життєвий цикл, і відповідно є ймовірність ловити «вічні» локи, поки механізм не буде нормально відлагоджений, тобто імплементація стає складнішою.
    — Пул конфігурується, сучасні БД нормально можуть обробляти тисячі конекшенів.

    Ще раз повторюсь, що я НЕ кажу, що зовнішні системи розподіленого блокування непотрібні. Рішення треба обирати зваживши всі фактори і вимоги. Може виявитися, що в реальності системою будуть користуватися не більше декількох сотень користувачів одночасно, а ми її будуємо в припущенні що «ми — Гугл» :) До речі, дуже рекомендую статтю — blog.bradfieldcs.com/...​e-not-google-84912cf44afb

  • Огляд книжки «Чистий код» Роберта Мартіна

    Проблема не в класифікації, а в відборі. Чому саме ці 25 серед сотень.

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

    Що у вас за робота, що вони регулярно зустрічаються?
    І коли зустрічався, наприклад, Visitor?

    В будь-якому проекті, де доводиться парсити кастомні вирази, Visitor з’являється. Такі проекти в мене були. Також пару разів доводилося кастомізувати поведінку LINQ виразів при взаємодії з БД, там для цього є клас ExpressionVisitor. Ще був проект, де користувачі конфігурували бізнес-процеси за допомогою діаграм — там здається теж використовували при візуалізації поточного стану процесу.

    Деякі з описаних в книжці паттернів давно вбудовані у фреймворки а іноді навіть і в мови, а деякі ми можемо робити навіть не замислюючись, що це хтось колись назвав спеціальним словом (той же Mediator). Тому може складатися враження що половина непотрібна.

    Саме неї.
    Бо коли такі книги пишуться без того, щоб кожну главу починати з «В усьому мають бути міра, норма і межа, а тепер слухайте», карго-культісти виростатимуть тисячами.

    Для мене є принципова різниця в подачі «дяді Боба» і GoF. У випадку Clean Code, він досить категорично напирає «робіть саме так і буде вам щастя». GoF дає книгу рецептів із серії «ось для такого кейсу можна використати ось це», а на мою думку, книга рецептів сама по собі карго-культ не породжує.

  • Використання транзакцій в реляційних базах даних: забезпечення надійності та цілісності

    В першому випадку ви відразу припускаєте, що обробка бізнес-транзакції розбита на шматки, які виконуються зовсім окремо. Якщо в цьому була реальна потреба з якихось міркувань, то окрема система розподіленого блокування дійсно може бути потрібна. Але, знову таки, будь-які ускладнення повинні бути виправдані — чи дійсно система очікує таке навантаження де без розбивки транзакції на окремі фрагменти ніяк і т.д.

    Другий випадок мені самому доводилося будувати, причому з батчами які і години можуть виконуватись. При очікуваному навантаженні і тих бізнес умовах які були, ми могли обмежити одночасне виконання батчів декількома сотнями, а ті що не влазять — ставити в чергу. Якраз використувували advisory lock для блокування. Декілька сотень конекшенів для PostgreSQL — це не проблема. До того ж, в залежності від внутрішньої реалізації батчів, вам може знадобитися дочитування даних в процесі обробки, а тут без живого конекшену буде дуже складно.

    Основна думка, яку я намагаюсь донести — не треба переускладнювати рішення, поки на це немає реальної потреби. Так, окремі системи для реалізації розподіленого локу можуть знадобитися, але це не значить, що при появі явного локування в вашому рішенні треба відразу їх додавати. Я вже зустрічав пару схожих випадків — один раз розробник просто не знав про вбудовані можливості сучасних баз даних, а в другому випадку знав, але сумнівався, що їх буде достатньо. Проговорили сценарії і виявилося, що все-таки достатньо.

  • Використання транзакцій в реляційних базах даних: забезпечення надійності та цілісності

    Ви підводите під якийсь дуже екзотичний чи штучний кейс :) В світі де намагаються зменшити час ексклюзивного блокування записів ви кажете що є потреба заблокувати щось на такий тривалий час, що навіть час життя конекшену до бази може бути проблемою. Наведіть приклад, будь ласка.

    І якщо навіть абстрагуватись від цього... Є два варіанти — або використовувати вбудовані засоби, які дуже прості у використанні і покривають 90%, або будувати «космічний корабель» з додатковими сервісами, харт-бітами та іншою магією. Складність альтернативного рішення повинна бути виправдана вагомими причинами специфічними для конкретного випадку. А відразу будувати щось складне тільки тому що «ну там обробка може зайняти X відсотків часу бізнес-транзакції» — дуже сумнівний підхід.

  • Огляд книжки «Чистий код» Роберта Мартіна

    Наскільки я розумію, мова йде не про викидання свіча з мови, а про те що досить часто на тому місці, де з’явився свіч, його мало би сенс замінити поліморфізмом. Чесно кажучи, не впевнений, що навіть в половині випадків це оправдано, особливо коли йде парсинг якихось вхідних даних, але раціональне зерно в рекомендації є.

    А щодо самого свіча — в його оригінальному вигляді він корявий. Якщо для якоїсь конструкції мови виникає формулювання «використовуйте, але пам’ятайте про...», то це поганий знак, бо обов’язково знайдуться ті, хто або не буде пам’ятати, або через банальну спішку вчасно не згадають. Я писав статтю на тему поганих рішень в мовах, і про свіч там є — blog.devgenius.io/...​anguages-32487008796#9db1. Але знов наголошу, що проблема не в свічі як такому, а деяких його особливостях, які не в усіх сучасних мовах виправили.

  • Використання транзакцій в реляційних базах даних: забезпечення надійності та цілісності

    А нащо динамічний таймаут, якщо час життя локів прив’язаний щонайменше до сесії? Впала сесія — вбився лок. В документації того ж MySQL написано:

    A lock obtained with GET_LOCK() is released explicitly by executing RELEASE_LOCK() or implicitly when your session terminates (either normally or abnormally)

    А в MS SQL та PostgreSQL є ще додатковий рівень гнучкості — такі явні локи можна прив’язувати до транзакції. Впаде транзакція з будь-якої причини — пропаде блокування. В інших базах даних може бути щось схоже, треба дивитися.

  • Використання транзакцій в реляційних базах даних: забезпечення надійності та цілісності

    Іноді дійсно є потреба робити блокування не прив’язане до конкретних рядків в базі, але для цього далеко не завжди має сенс використовувати додаткову систему. В сучасних базах є такі механізми блокування: advisory lock в PostgreSQL (www.postgresql.org/...​cking.html#ADVISORY-LOCKS), application lock в SQL Server (learn.microsoft.com/...​sql?view=sql-server-ver16), lock functions в MySQL (dev.mysql.com/...​en/locking-functions.html), і т.д.

    Те що вам сказали «дба в світерах» скоріш про lock escalation, який існує не в усіх базах (в тому ж Oracle та PostgreSQL його немає), і в першу чергу він полягає саме в тому, що ви написали — замість того, щоб блочити велику кількість окремих «маленьких» об’єктів бази, блочиться більш високорівневий. Але ця поведінка нічого не каже про сумісність лока на оновлення і звичайного лока на читання на тому самому об’єкті. Ну і хай lock escalation працює, якщо мої селекти без UPDLOCK сумісні з цим блокуванням — то навіть якщо UPDLOCK буде на всій таблиці стояти, нічого не зміниться в поведінці. Треба ще подивитись документацію SQL Server, але елементарний тест з двома SERIALIZABLE транзакціями, які вибирають той самий рядок, але з різним рівнем блокування, показує що обидва читання один одному не заважають.

    Підтримав: Valeriy Shvets
  • Огляд книжки «Чистий код» Роберта Мартіна

    Про «Clean Code» в мене виникали схожі думки :) Пригадую пару випадків, коли намагання дослівно слідувати рекмендаціям Мартіна робили тільки гірше, хоча девелопер цього не розумів. Але сказати що ця книга непотрібна — теж не можу. Адекватні рекомендації там є, ну і є про що подискутувати.

    А з приводу ГоФ — не згоден. Класифікація найбільш загальних патернів дуже непогана, і сформульована в практичному стилі «вам треба зробити ось таке при таких-от умовах — використовуйте такий паттерн». Хочу також звернути увагу, що всі описані патерни не дуже прив’язані до прикладної специфіки задачі: пишете ви взаємодію з базою, ЮАй, рендерінг репортів чи гру — майже будь-який з них може стати в нагоді. Хіба що Interpreter вибивається своєю специфічністю, я б його в цей ряд не додавав. Ще можна поскаржитись на Flyweight та Prototype що це непотрібна екзотика. Також можна сказати що Builder сформульований в переускладненому вигляді. Але все інше зустрічаеться регулярно — щось рідше, щось частіше. Для книги написаної в 1994 році так зовсім успіх.

    Що дійсно напрягає, так це карго-культ, який на базі таких книг виникає: штучне розрізання коду на мільярд функцій (бо дядя Боб так казав робити), створення 100500 класів для простої задачі (бо інакше «порушиш сінгл респонсібіліті»), всі ці намагання використати якомога більше патернів на сторінку коду, питання на співбесідах «назви три категорії паттернів», «а які біхевіорал паттернс ти знаєш», і т.д. Але то далеко не завжди проблема книги :).

  • Огляд книжки «Чистий код» Роберта Мартіна

    Сподіваюсь це сарказм :)

  • Використання транзакцій в реляційних базах даних: забезпечення надійності та цілісності

    Я не бачу де в статті вказано, що вона саме про SQL Server. Стаття взагалі про «сферичні транзакції в вакумі», мабуть мається на увазі ANSI стандарт. Єдиний рядок де згадуються конкретні технології:

    У багатьох реляційних базах даних, як-от PostgreSQL, MySQL, Oracle, є можливість використання транзакцій через мову запитів.

    , а коли мова йде про Repeatable read, то тут все змішалося:

    Snapshot isolation, який ще називають Repeatable read

    В тому ж SQL Server це два різних режими ізоляції...

    Підтримав: Ivan Pyrog
  • Використання транзакцій в реляційних базах даних: забезпечення надійності та цілісності

    REPEATABLE READ не завжди значить більше блокування — дивіться на його реалізацію в PostgreSQL, або на SNAPSHOT ізоляцію в SQL Server.

  • Сюрпризи і пастки JSON API, GraphQL і gRPC: як зробити правильний вибір

    Swagger, який потім був переіменований в OpenAPI, почали розробляти в 2010 році (en.wikipedia.org/...​iki/OpenAPI_Specification), і про нього більшість девелоперів в курсі.

  • Сюрпризи і пастки JSON API, GraphQL і gRPC: як зробити правильний вибір

    Щодо документації та синхронізації моделей все одно не розумію різницю :) В GraphQL ви описуєте загальну модель для клієнта і сервера, в gRPC (Protobuf) — теж, і з OpenAPI можна зробити так само. Можете підтримувати загальний файл моделі для API у форматі OpenAPI специфікації, і генерити клієнтські проксі та серверні стаби автоматично. І в цьому випадку я не бачу різниці між технологіями в аспектах документації, автогенерації, та загальної моделі між клієнтом та сервером. Те що багато девелоперів пишуть бойлерплейт для REST API — досить часто проблема необізнаності.

  • Сюрпризи і пастки JSON API, GraphQL і gRPC: як зробити правильний вибір

    Рекомендую краще ознайомитися з тим що таке OpenAPI специфікація і який тулінг для неї існує, бо деякі речі написані про «JSON API» не відповідають дійсності. Генерація коду існує давно — можете подивитися github.com/...​PITools/openapi-generator або github.com/RicoSuter/NSwag. Про документацію — не зрозумів висновків. Навіть якщо ви опишете тільки схему АПІ без жодного рядку опису — і «плейграунд» буде доступний, і код зможете генерити. До того ж, в деяких платформах можна не писати файл зі специфікацією окремо, а досягати тих самих результатів анотаціями на методах в коді вашого сервісу: підключили бібліотеки (той же Свагер), анотували методи/контролери, і у вас вже є плейграунд на спеціальному URL у вашому сервісі. В чому тоді такий варіант з документацією і «плейграундом» програє GraphQL?

  • Чи може PostgreSQL з його JSONB замінити MongoDB

    Два дуже простих базових сценарія, в яких запити зі статті будуть релевантними:
    — Об’єкти з динамічною структурою.
    — Вложеність і масиви є, але пошук і фільтрація йде по простим полям.

    Другий кейс може дати додаткове навантаження на додавання та оновлення даних.

    Я згоден з тим, що пошук по елементам масиву, або пошук по атрибутам об’єктів з масиву — це важливий сценарій для документних баз і його дійсно не вистачає. В PostgreSQL подібні запити реалізуються тільки через GIN індекс, який далеко не в усіх випадках добре працює. Я планую додати ще один пункт з застереженнями в статтю, і додати масиви в майбутні бенчмарки.

  • Чи може PostgreSQL з його JSONB замінити MongoDB

    Чому ви вирішили, що пошук/сортування ведеться на основі індексів? Ви дивились плани ваших запитів?

    Я не стверджую що у всіх сценаріях використовувалися індекси. Так, в кожному з випадків я дивився плани виконання. І далеко не у всіх використовувалися індекси, про що я писав в коментарях для кожного запиту — в яких випадках повний скан, в яких у постреса і монги різні за природою плани і т.д. Мій коментар про «Чи має сенс порівняти швидкість фільтрації за індексом на терабайті даних» — саме про те що в ньому написано, без якогось додаткового контексту. Тестити фуллскан на терабайті — не впевнений що має сенс.

    Наприклад, є поле, яке має тільки 2 значення, у колекції/таблиці дані поля розподілені 50/50, у такому випадку індексування цього поля не додасть якогось перфоменсу.

    Це очевидно, але все одно не розумію до чого цей коментар.

    Я розумію, якщо є бажання погратися з індексами, але навіщо для цього робити бенчмарк?

    Різні реалізації індексів в різних базах даних можуть мати доволі неоднакову швидкість навіть на тих самих даних. Тому і цікаво подивитись яка різниця в швидкості двох баз при схожих планах виконання. Подивіться, наприклад, запити 1-3 і 8 із статті — плани для композитних індексів там еквівалентні, а різниця в часі є, хоч все одно мова йде про одиниці мілісекунд. А ось коли даних буде набагато більше ніж оперативи, то різниця імплементацій виявить себе ще сильніше. Хто переможе — ще не знаю.

    Інша ситуація — окремі індекси на двох полях. Припустимо я отримав плани і бачу що MongoDB йде по одному з індексів, а PostgreSQL виконує bitmap scan по обом. Звідки я знаю що буде працювати швидше?

    P.S. у мене є досвід роботи з колекцією mongodb, розмір якої більше 2 млрд документів, в залежності від результату, пошук виконувався мілісекунди/десятки мілісекунд.

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

    з моєї точки зору для 11 млн простих документів/рядків не має значення, яку БД використовувати (mongodb, postgresql, mysql ..., JSON/regular tables), вибір буде залежати від кошторису використання і експертизи команди підтримки.

    Тут можна подискутувати на тему того, що факторів існує більше, але основний висновок з цієї статті — «JSONB в PostgreSQL можна розглядати як альтернативу колекціям MongoDB». Я не кажу що MongoDB не потрібна. Але зустрічав упередженість на тему того, що PostgreSQL в будь-якому випадку буде програвати при роботі з JSONB, тому що MongoDB вже багато років оптимізується під документні сценарії, а в PostgreSQL це якийсь «едж кейс». В цій статті можна побачити що при таких сценаріях і даних це не так. Чи треба проводити подальше тестування на більших даних та інших сценаріях — звісно так, про що я теж пишу.

  • Чи може PostgreSQL з його JSONB замінити MongoDB

    або ви неправильно користуєтесь MongoBD або не розумієте для чого створені MongoBD, Elasticsearch, etc.

    Сучасні пост-реляційні бази вже вміють багато того, що раніше було тільки у різних NoSQL рішень, і різниця стає не такою очевидною (якщо що, з тим же Еластиком через його природу різниця очевидна до сих пір). Цікаво почути вашу думку про те, для чого саме MongoDB і чому PostgreSQL потенційно не може закрити ці потреби.

    11 мільйонів рядків — це дуже смішно

    Вже відповідав раніше. Як можна бачити з тестів — в багатьох випадках швидкість вже погана навіть на такому об’ємі. З ростом об’єму вона не покращиться. Чи має сенс порівняти швидкість фільтрації за індексом на терабайті даних між двома базами — звісно так, але це матеріал для майбутніх тестів. Я у висновках наголошую на тому, що тести покривають тільки частину сценаріїв, і не кажу що MongoDB не потрібна. Окрім того, навіть на такому об’ємі можна спростувати деякі міфи, які я чув навіть від досвідчених розробників: «GIN індекс в PostgreSQL набагато швидший за звичайні індекси», «MongoDB завжди більш ефективна для роботи з документами, ніж JSONB в PostgreSQL», «MongoDB швидше виконує агрегації» і т.д.

    Стверджуєте що Postgres теж може горизонтально масштабуватися але тести проводите на одній ноді
    Навіщо робити запис у 100 паралельних потоках на одній машині вбиваючи її? В реальності так ніхто не робе. Можна горизонтально масштабувати та отримати більший приріст

    Щоб порівняти базову ефективність енджинів, цього достатньо. Тестування шардінгу і терабайтів даних — це окремий сценарій, в якому і запити можуть бути інші. Якщо у вас є хороші приклади сценаріїв/запитів, для яких на вашу думку має сенс зробити бенчмарк — поділіться, будь ласка.

  • Чи може PostgreSQL з його JSONB замінити MongoDB

    Так, як буде час, хочу повторити тести для нових версій цих баз.

← Сtrl 123456 Ctrl →