Десять лет назад на доу выходили статьи в агитацию за NoSQL (типа таких: dou.ua/...ta/articles/nosql-vs-sql), куча хайпа и т.д.
Я в своей жизни ни разу не использовал NoSQL, весь хайп прошел как-то мимо, расскажите, NoSQL вообще живо или уже сдохло?
як і з більшістю інших технологій, хайп закінчився, всі розібрались, де треба використовувати, а де ні, і мовчки працюють.
NoSQL хайп закончился?
Хайп можливо. По факту вони вже увійшли в мейнстрім.
Дінамо — в багатьох амазон проектах.
БігКвері — в гуглклауд проектах, для деяких проектів вона причина переїзду на гуглоклауд.
Редіс — стандарт для кешування, окрім того популярна у всіляких ігрових проектах і не тільки.
Монго — відсоток не скажу, але це десятки відсотків, а не одиниці.
Афіна/Хбейс та інші бігдата бази — живі, бо їм альтернативи немає.
Касандра наче здулась, але це дуже суб’єктивно і не факт (в попередньому коменті її згадали як мінімум).
Графові БД — це те що не взлетіло.
жах. Як можна нормально мірятися своїми наносекундами, коли немає функціоналу додавання зображень?
Их же можно как datastream добавить?
то я невдало сформулював фразу, просю пардону. Мав на увазі функціонал зображень тут, у коментарях. Щоб, значить, аргументовано показувати свої аргументи (поряд з лінійкою чи, там, сірниковою коробкою). Просто там нижче пани наносекундами мірялися, от і захотілось пошуткувати. У нас не вийшло.
На постгресі гібрідне щось роблять (він непагано вміє в JSONB з індексуванням по даним).
Давно не хайп — а еще один способ сохранения данных со своими особенностями, не для всего проходит, скажем хорошее дело — когда писать в таблицу нужно много, а читать относительно мало. Среди самих NoSQL тоже большой разброс, документ ориентированные типа Mongo, большая таблица — типа Big Table, HBase и Dynamo DB, граф ориентированные — типа Neo4J. Но есть и гибридные решения — Google Claud Spanner и Casandra. В микро-сервисной архитектуре типа — Amazon 6 используют много баз, посему место есть для всего. Однако от граф ориентированных, для обычных CRUD — очень рекомендую не связываться. От чего был хайп? По сути маркетинг Google GCP, где был их тендер с научными исследованиями в которых учёные Беркли дали обоснования отказа от реляционной модели, для часто встречающихся задач в поисковых машинах и социальных сетях, когда писать надо очень часто, много и с дубликацией данных — а читать относительно редко. Много народу восприняло это как сигнал с отказу от всего что было раньше и «революцию», стали использовать где не попадя с переменным успехом, потом уже откатывали переделывали куски где нужно на реляционную модель данных и т.д. Зато сами claud-ы и контейнеризация стали must have. Даже самые дикие монолиты на них перебросили, что в общем сильно лучше чем когда приходилось писать свой велосипедный софт, типа Lens — чтобы автоматизировать управление кластером из 17 блейд серверов по SSH. Сегодня если не знаешь Docker и Kubernetes — придется срочно учить.
Вчити треба cgroups
навіщо? Для керування автомобілем треба вміти бодяжити паливо?
Не знаю за автомобілі, але щоб робити нормальні літаки, в школі не треба прогулювати фізику.
так, я теж вважаю, що бортпровідниці мають захищати кандидатську по фізиці, окрім як проходити бразильский тест
Ми ж про розробників говоримо
розробників докеру, чи розробників всього іншого, котрі той докер/lxc/etc просто використовують?
Для керування автомобілем треба вміти бодяжити паливо?
Вміти-не вміти, але знати, що його можуть розбадяжити — треба
До речі, кіловати розбадяжити важче
це ж різні речі. Я от знаю, що є cgroups, що поверх яких зроблена легка контейнеризація. і все. Я навіть не впевнений у вірності моєї попердньої фрази. Але навіщо мені знати деталі, якщо я докером використовую, а не розробляю його? Хтось узагалі слабо розуміє чим докер від віртуалки відрізняється (жителі вінди, звісно, бо для них — нічим) і це геть не заважає їм користуватися докером у своїх цілях.
Насколько я знаю, NoSQL отлично совмещается с in-memory Database, нечто вроде программного кеша. А вот с классическими базами с постоянным хранилищем это подход не очень, там до сих пор хорошо работает реляционные.
Все то же самое, что и с (в обратном хронологическом порядке):
Блокчейном
GPGPU
Виртуализацией
Managed
COM
...
ЯВУ
Ассемблером
Технология заняла свою нишу, где тихо-мирно выполняет оптимальные для себя задачи.
А хипстота как обычно, похайпила пару лет, да побежала дальше совать во все дырки очередное нечто, что, вероятно, через десять лет тоже будет маленьким базвордом в своей нише.
Я б сказав що все ж скоріш сиквел вмер, не пам’ятаю коли останній раз доводилося не дай бог кликати дба затюнити якісь квері, розбирати бізнес логіку в хранімках на сіквелі, паритись за те що пошук, фільтрація, сортування по сотні критеріїв туплять на терабайті данних, чи потрібно було тюнити збереження данних і втрачати спринти дев годин щоб розкласти якийсь умовний батч ріквест на півсотні нікому непотрібних рілейшинів під эксклюзивними локами. Весь цей хворий майндсет у минулому є надія.
Скл чудово живе на монолітах з гігбайтами даних, чи в скл єйжур сервісі, де немає реплікації та терабайтів даних. Як раз таких проектів більшість у нашому аутсорсі, тож не дивно що люди дуже рідко бачать щось інше.
Скл чудово живе на монолітах з гігбайтами даних
Зовсім не чудово, це дуже залежить від лоада
Два роки тому ми натягували хезелькаст і редіс на критичну базу десь під ~90г, а чого — щоб все швидше запрацювало і скейлилось і щоб витягло 300 замість десь 120 tps в піку але без геморного переробляння туєвой кучі інтеграцій
Проекти на скл не дуже добре скейляться, якщо вони спочатку на це не розраховані. Ну і якщо це не оракл і не якась неєбічнодорога пузата железяка
Щось 120/300 tps якось замало навіть для заліза 15 річної давнини. Але звичайно залежить що саме за t — транзакції там були, якщо в кожній сотні sql-запитів, чи якісь фулскани по мільйонам записів, тоді так, миттєво воно працювати не буде.
То не дб tps а сервіс лейер був платіжного провайдера. Там на кожну tx був ворквхвлоу і з дюжиною запитів у базу різного калібру
Ох уж ця довжина лососів на рибалці
300 транзакцій в секунду це 770 млн транзакцій в місяць. Якщо Приват має 15 млн клієнтів та кожен проводить всього по
Алеж тут в нас кожен перший пише навантаження в десятеро більше, що має Приватбанк.
На словах всі дартаньяни, а на практиці важко знайти сайт що реквест обробляє швидше за пів секунди. Навіть якщо його відкривати в чотири години ранку в понеділок.
навантаження в десятеро більше, що має Приватбанк.
Нуууу да, чо скромнічать, а до речі до приватбанк і ощад у нас коннектори були ;)
Лососі у нас довгі :))
Скандинавський платіжний інтегратор-середнячок мав вього лише на одній з своїх платформ десь 300 авторизацій на секунду в ± пікові години. Це було ще років 10 тому. Тому не пишіть в такому тоні те, чого не знаєте напевно. А це саме той випадок.
Можна посилання на сайт цього інтегратора ? Зараз в консолі по F12 подивимось час обробки реквесту «не в піку».
Зараз в консолі по F12 подивимось час обробки реквесту «не в піку»
Ти навіть не уявляєш наскільки ти показав як далеко ти від теми сорі
Лососями мірятись тут не має сенсу навіть і щось тобі доводити.
Ти навіть не уявляєш наскільки ти показав як далеко ти від теми соріЛососями мірятись тут не має сенсу навіть і щось тобі доводити.
Смішні ви. Звичайна хештаблиця оброблює запит в
Звичайна хештаблиця оброблює запит в5-10 наносекунд, що є 100 млн запитів в секунду. Але яке то відношення до користувача, якщо він чекає на виконання свого запиту1-2 секунди. Пишіть любі цифри. То до сраки.
Що ти хочеш почути? Що не всі транзакції на світі такі з якими ти працюєш?
До чого тут це піськомерство?
Ти прав, в тебе лососі кращі, іди погуляй і будь довольний
А сенс? Все одно без авторизації нічого поміряти не вийде Чи контракт з ними підпишете?
І щось не розумію, що цим хочете довести? Що їх сервери не обробляють 300 реквестів на секунду?
Вам дві людини, які САМІ працювали з такими системами вже написали, що цифри цілком реальні.
А стільки пафосу і категоричності, неначе спілкуюсь з джуном-фронтендером, який тільки-но прочитав статтю про NoSQL і тепер всім розповідає які круті хештаблиці і як круто ними замінити SQL бази у платіжних шлюзів.
Все одно без авторизації нічого поміряти не вийде Чи контракт з ними підпишете?
То яб хочаб поміряю невірно введенний пароль.
Що їх сервери не обробляють 300 реквестів на секунду?
На кешах та сервері що займається лише авторизацією — так, можна повірити
Ну в кожного свій досвід. За останні років десять завжди були проекти де на добу було 50M+ sql-запитів до бази. І до мільярду на добу, це простих sql-запитів, але великий відсоток insert/update. Http реквестів звісно набагато меньше.
Не сперечаюсь з тим, що масштабування класичної бази просто робити тільки вертикально. Та і треба розуміти що і для чого робиш коли є навантаження, використовувати як black box і сподіватись що воно там якось саме краще зробить не вийде.
де на добу було 50M+ sql-запитів
Цікаво лише що на виході, як швидко оброблено запит від користувача. А не гівнокодери що трафік по колу гоняють між сервісами.
По різному, в залежності від запиту, зазвичай соті або десяті частини секунди. Складні репорти можуть довше. Це ж загальна кількість запитів, щось взагалі респонсу не потребує, щось крутиться в фоні — розрахунки, агрегати.
зазвичай соті або десяті частини секунди
Це
50M+ sql-запитів до бази
800к+ запитів на добу.
Напицтів так напицтів.
І? Багато, мало, чи що?
Десятки тисяч нескладних запитів в секунду база на гарному залазі (десятки ядер, 100+ гіг оперативи, nvme диски) тягне 24/7 і датасет звісно не 3 рядки, а сотні гігібайт і мільярди записів сумарно по таблицях.
І я кажу не про теорію, а практику.
Звісно що можна не вірити, в мене нема мети тебе переконати.
І? Багато, мало, чи що?
Не мало і не багато. Я лише хочу побачити сайти тих рокстар що обробляють по 50 млн запитів на добу.
Ось було цікаво, відкрив Приват латенсі 450мс. Доу латенсі 700 мс, при трьох каліках що переглядають, та одному що постить одне повідомлення раз на хвилину.
То де ті вологі мільйони побачити. Дайте урл. Багато не прошу, хочаб х2 від мого пінга що складає на оптиці <10мс.
Рукалице.пнг
Ось було цікаво, відкрив Приват латенсі 450мс. Доу латенсі 700 мс
Діду Панасе, пропоную вам зразу почитати про розподілені навантаження, кластеризацію, лоадбалансери різних рівнів, про anycast
Як мінімум морда сайта — це на апі запити, але мені здається вже і так ти досить набренькав про себе і всім зрозуміло що пояснювати це зайве в твоєму контексті
А то як міряти перформанс приватбанка по латенсі з бравзера і робити якісь висновки
про лососів з умним відом — це якось дуже для мене кучеряво.
Ти б не пройшов інтерв’ю ©
А то як міряти перформанс приватбанка по латенсі з бравзера і робити якісь висновки
про лососів з умним відом — це якось дуже для мене кучеряво.
А в чому проблема? Джентельменам вірять на слово? Доречі взяв wikipedia.org, відкривається за 40мс. Вже видно що щось оптимізували, працює добре і швидко.
А всякі мамкіни оптимізатори наміряли мільйони запитів між своїми сервісами, а як показати експірієнц користувача, то соромно урл привести.
"Ві нічєво нє знаєтє о распрєдельонай архітєктурє, мі мєрялі в кансолє на локалхастє, а нє браузєрє!"©
Доречі взяв wikipedia.org
Зрівняв *** з пальцем, статику з вікіпедії з бізнес-транзакціями, скажи ще щось розумне. Ти або не розумієш або просто тролиш або думаєш що все знаєш. Нема бажання далі
Краще не позорся, я тебе прошу, ну просто умоляю
Зрівняв *** з пальцем, статику з вікіпедії з бізнес-транзакціями
Звісно статика. Ця статика дійсно видає свої тисячі запитів в секунду.
А ваші запити видають 10 запитів в секунду. І це в кращому випадку.
Звідси і латенсі в браузері.
10 запитів на ядро application server’а (хоча для node.js чи взагалі event loop там трохи не так).
А ядер то більше зазвичай і можна горизонтально скейлити додав ще «тазиків», головне щоб сховища чи інші сервіси тягнули чи якось відповідно могли скейлитись.
Я хз, якщо бекенд обробив запит за 0.1 сек то це більш-менш норм. Зараз фроненд в броузері цими новомодними js фреймворками додає не меншу латенсі для користувача.
за 0.1 сек
Про 10 запитів вірю, про 300 — вже ні.
І скейлити там нема чого, в більшості випадків. За принципом паретто 80% запитів йдуть до 20% таблиць, вониж і вузьке місце
А ваші запити видають 10 запитів в секунду. І це в кращому випадку.
Звідси і латенсі в браузері.
Лікбез, тільки бо в мене хороший настрій
Запити в браузері йдуть з одного клієнта на один облуговуючий бекенд _сайта_
Міряти лоад транзакцій треба розподілено, наприклад locust, посилаючи _синтетичні транзакції_ на ендпойнт з кластера _апі-сервіс_
_бізнес-транзакції_ не кешуються, в той час як вікіпедія має стопіцот кешів і взагалі віддається скоріше за все з CDN. І латенсі того CDN ти і міряєш в браузері, а ти думаєш що це латенсі вікіпедії
І да
ваші запити видають 10 запитів в секунду
Може бути й так, хоч це прям вже як на мене важкий крайній кейс.
Латенсі свого броузера можеш роздрукувати й підтертись, тільки вибери папір для друку потонше
Те що ти робиш зараз це застосовуєш свої знання оптимізації сайтів до зовсім перпендикулярно інших матерій, і думаєш що це щось значить, а воно не значить ніхіба
Все далі сам
То ти сам відповів на своє питання.
Там де кеш, або NoSQL, там є швидкість.
Там де мамкіни програмісти вижимають з SQL тисячі запитів, це треба на телебачення.
SQL це саме всрате рішення що тільки можна придумати (особливо построчні не колоночні)
1. Третина бази айдішники, які нахрін нікому не потрібні
2. Масштабування близьке до нуля
3. Всі агрегати максимально розмазані по секторам диску і кожен раз збираються орм разом, на кожен запит
4. Трафік що йде — пічаль-біда
5. Блокування на данних, максимальний кринж. Трохи краще в версіонних субд.
Все це залежить від кейсу і від проекту до проекту
Кожен пункт
мамкіни програмісти вижимають з SQL тисячі запитів, це треба на телебачення.
Легко, залежить від запитів, норм сервак зараз наприклад таке зжує запросто якщо ми просто про запити в тестову якусь базу
www.2ndquadrant.com/...nce-since-postgresql-8-3
NoSQL, там є швидкість.
Легко ні залежить теж
Все залежить
Бізнес-тразакції — це не запити в базу, це можуть бути десятки запитів на одну транзакцію. TPC-H це просто певний паттерн таких транзакцій. Лоад завжди міряється специфічно до бекенда
Ті бенчмарки до сраки. Вони ганяють одні й тіж дані по L2-L3 та кешу постгреса в колі.
Доки я не побачу в своєму браузері
Ping Time+5 мс то не має ніякого значення.
Бо згідно їх бенчам 1мс забирає субд, то хто їсть решту 300-500мс при відповіді в браузері?
Може тому, що вони наміряли якісь дані, які орм ще потрібно зібрати до купи, розмапити, сгенерувати сторінку.
А тіж документоорієнтовані віддають вже готові агрегати.
Ті бенчмарки до сраки
Слухай набридло реально, перше бляха травня все таки
Тобі видніше, міряй перформанс у бравзері ¯\_(ツ)_/¯
Ось тобі приклад приземленого real use case
developers.redhat.com/...ts-single-sign-technology
The key dimensions of an SSO project are the number of user session openings per second and where the user passwords are stored.
SSO can sustain around 75 TPS per physical core if the user passwords are stored in a third-party system (an LDAP directory, for instance) or if the PBKDF2 function is configured with one iteration.
Otherwise, SSO sustains slightly less than 10 TPS per physical core.
Refreshing tokens is less costly: SSO can sustain around 200 TPS per physical core.
Introspecting a token is pretty cheap. SSO can sustain around
The choice of the database has no significant impact on performance.
І keycloak це просто _один_ компонент архітектури, де може бути купа ботлнеків подібних до тих 10 tps/core
Ха-ха )
Не спадало на думку що можна використовувати одночасно як sql-бази, так і nosql сховища. Ось не повіриш, так буває, майже завжди в великих або навантажених проектах. І так, sql не обов’язково використовувати, залежить від задач та вимог до даних.
Цікавий троль, токсичненький )
Але бачу що трохи очі відкрились що бази можна використовувати не тільки для сайта бабусі з кількістю користувачів 0.5 за рік. Хоча так, звісно всі проблеми не вирішують і своїх забобонів вистачає.
Добре. Що найчастіше використовуєш? Не для кешу та якогось olap, а для звичайного зберігання данних, ну наприклад того ж каталогу розетки? Монгу чи щось цікавіше?
Я навіть без жартів запитую )
Не спадало на думку що можна використовувати одночасно як sql-бази, так і nosql сховища
А не спадало на думку що SQL можна викинути з цього рівняння? Він нормальний лише OLAPи якось крутити. І то, навчились більш меньш крутити ті репорти на колоночних субд, до цього 30 років не правильно крутили.
Що найчастіше використовуєш?
Я вже старий для цього, на пенсії.
Лише кнопку F12 в бравзері вмію натискати.
Я вже старий для цього, на пенсії.
Лише кнопку F12 в бравзері вмію натискати.
Ну слухай що тобі ще відповідати, якщо тобі показуєш кваліфікований індустріальний бенч чи конкретний кейс, а тобі він до сраки, бо в тебе в бравзері латенсі у вікіпедії 40мс?
Ось тобі результати по системах
www.tpc.org/...ts/tpch_perf_results5.asp
А не спадало на думку що SQL можна викинути з цього рівняння? Він нормальний лише OLAPи якось крутити.
RDBMS і NoSQL може віддавати на ура, тобі кажуть що це не показник перформанса системи бізнес-системи, як і твій бравзер. Але як горохом апстєну
Шо незрозуміло дєду?
Якщо б ти внучок був трохи досвідченішим, то знав би.
Що є п***ьош, є великий п***ьош, а є бенчмарки.
Це накшталт договору в брокера. Тобі показують на папері 250% річних на депозит. Але згодом на всіх комісіях ти отримуєш 0.1% від обіцяного.
Ти як клєрк з МММ мені показуєшь цифру в 250% а в гаманці в мене по факту 5 копійок від обіцяного (в бравзері).
То де гроші, Люсьєн?
Що є п***ьош, є великий п***ьош, а є бенчмарки
То де гроші, Люсьєн?
У бравзері на f12
Не дочитав до?
Лоад завжди міряється специфічно до бекенда
Бачу ти тут тільки токсік троль, це без мене
（︶_︶）╭∩╮
Бачу ти тут тільки токсік троль, це без мене
Злив зараховано.
Але трохи сумно, троль нині не досвідчений пішов. Я навіть впевнений що Люсьєн не знає що таке тест TCP-H,
а це тест всього на 8 табличок, коли в реальній субд тих таблиць кілька сотень. І моделює він самий базовий склад з найпримітивнішими запитами. Привезли на склад, відвезли зі складу. Прості апдейти.
Тож в реальній субд, та ще й з бекендом, і все обвязане секуріті, історієй і тд., ти ті цифри ніколи не побачиш.
Він нормальний лише OLAPи якось крутити
Скоріш навпаки, на олапах, коли треба зробити group by більше ніж по 10M записів, воно працює фігово, секунди, а може навіть і пів хвилини. Для цього big query / clickhouse майже на 2 порядки краще. А на oltp непогано працює.
Я вже старий для цього, на пенсії.
Ну відпочивайте пане, старість то святе.
Цікавий просто досвід, хоча той каталог розетки можна де завгодно зберігати, якщо данні майже read only.
Для цього big query / clickhouse майже на 2 порядки краще.
Клікхаус, Вертіка і інші то і є колоночні субд.
Ти би розібрався що є оракл, мс скл, постгрес, та що є колоночні субд. В чому різниця. Та не путався би між ними.
Бог ти мій, а я щось писав що то не колоночні. Звісно вони і є. Я ж і кажу, що коли проект великий, то багато технологій використовуються, вони теж для аналітики в додаток до класичної реляціонки. За останні багато років не пам’ятаю щоб не було десь ще redis’у і часто elasticsearch (хоча sphinx для full text пошуку подобався більше, але сучасні тренди, вони такі).
Ого у діда лосось відріс від міряння латенсі в браузері по f12 аж до колоночних субд всього за півдня?
В мене тут за спиною латенсі в 83 нс жужжить в піку, якась твоя вікіпедія з браузером мєдлєнна як равлик. Хочеш лососями помірятись?
83 нс
Отжеж невгамовна малеча.
Мілісекунди в бравзері переплутав з наносекундами. А це, на хвилиночку, про*ти в оцінюванні 6 порядків.
Так і живемо.
Отжеж невгамовна малеча.
Мілісекунди в бравзері переплутав з наносекундами. А це, на хвилиночку, про*ти в оцінюванні 6 порядків.Так і живемо.
Так я ж не про бравзер
Если в наличии есть единственный инструмент — молоток, все проблемы кажутся гвоздями ;)
Q.E.D.
Забрехався джун вкрай.
Добре, 83 наносекунд це всього кілька (до десяти) асемблерних команд.
Покажи, що за запит в тебе вмістився в кілька команд. Доречі лише call пустої функції в Сі це вже
Та робили тут хешмап в 1u формфакторі підключений до 100gbps
Сорян не нс, а мікросекунди 83 us
Це щось міняє, в тому що ти не шариш про що ти балакаєш? Як там латенсі в бравзері?
Сорян не нс, а мікросекунди 83 us
Чисто поржати.
Взяли кондитера, а він тонни з кілограмами плутає.
Або взяли портного, а він кілометри з метрами плутає.
Ти би спочатку з шкільною програмою розібрався по інформатиці, а потім вже сюди на доу.
Це не завжди сайти, з чим працював:
— онлайн трекінг авто, де десятки тисяч авто постійно надсилають координати, які треба писати, робити всілякі агрегати для репортів (це в бекграунді)
— мобільні онлайн ігри, коли майже на любий клік йдуть запити на сервер і коли ти десь рекламуєшся в сторі, то одночасно набігає куча нових користувачів на додаток к існуючим
— музичний онлайн стрімінг, який «фічерився» в microsoft-маркеті, та рекламувався на якихось платформах.
— соц.мережа для школярів, яку на mtv російському (прости господи) трохи рекламували більше 10 років тому
— фінансовий сервіс, де все йде по api і латенсі там не важливе.
Більшість цих всіх проектів або вже закриті, або там зараз нема того навантаження. Посилання саме на сайт працюючий і щоб туди можна було зайти подивитись, такого не дам.
А взагалі то, 50M QPS, це десь 5M requests на добу, тобто в середньому 60 http запитів на секунду. Думаю у розетки і інших популярних сайтів точно є таке навантаження.
І ми ж розмовляємо не про латенсі між користувачем і сервером, а виключно про бази данних. Тому що багато чого впливає на кінцеве латенсі.
Мав базу Oracle (при чому сама база спроектована була дуже погано, не дивлячись на те, що офіційно це дизайн самого Oracle — ATG, та ще додатково індійцями і нашими спаскуджена) яка на одному ноді без жодних реплікацій тягнула 800 TPS. Це було десь
Скл чудово живе на монолітах з гігбайтами даних, чи в скл єйжур сервісі, де немає реплікації та терабайтів даних.
Яб сказав і в цій ніші сиквелу прийшов закономірний кінець — відкриваєш схему а там 50% на json пропертях з нативною підтримкою документного апі , і хвала тим своєчасно зрозумів що розробити софт набагато швидше і з використанням рсубд, якщо нормалізацію робити під потреби конкретні, а не по замовчуваню.
Бо ALTER TABLE це менінгітно.
А додати поле з даними, по якому нема індексу, простіше в JSON чи XML. Здається ще в MS SQL 2005 було.
І ця база окрім гарного OLAP, вміє так саме добре з OLTP працювати? Ну там вміє в транзакції, acid, mvcc, в тысячи апдейтів за секунду? З опису виглядає що це якийсь bigquery/redshift/vertica/clickhouse і на olap вони звісно дуже гарно працюють, але щоб це було основним сховищем данних, не можу собі уявити. Поки що не зустрічав silver bullet базу, яка вміє покривати всі кейси. Все одно постійний зоопарк з різних технологій, які краще для конкретних кейсів в проекті — реляціонки/транзакції, кеші, full text search, timeseries db, olap.
І ця база окрім гарного OLAP, вміє так саме добре з OLTP працювати?
Яка база? У мене описані підходи до вирішення задач, а не бази. І доречі, в моєму описі немає ніодної OLAP задачі і ні слова про агрегацію — не знаю з чого він тут взагалі.
У нас монга, как основное хранилище. Все отлично на ней крутится. Единственное что
фільтрація, сортування по сотні критеріїв туплять на терабайті данних
там так же тупит и нужно что-то типа clickhouse для подобных сложных запросов.
За останні 3 роки, декілька разів довелось переробляти частину продукту NoSQL на SQL. Бо те що виходило — не працювало. Воно як з будь чим — що занадто то не добре.
Буквально в трех випадках, майже усе поїхало на Postgress, залишалась лише якась специфічна частина — на NoSQL, зазвичай одна дві таблиці на Big Table like. Найбільша засада неодноразово була із Neo4J. З точки зору e Commerce — вона дуже цікаво виглядає, позаяк скажімо каталог товарів — це ієрархічна структура данних типа — дерево із вузлами каталог-категорія-підкатегорія-товар-товарна позиція, в яку рідко пишуть — але дуже часто читають та роблять пошук. Але на практиці — реляційна база та кешування, разом із тюнінгом навантаженних запитів — працюють суттєво краще за граф орієнтовну базу. Тоді як граф оріентовна БД, на тюнінг часу якої ніби то можна не витрачати часу — не тримає навантаження і звалюється із OutOfMemory доки їй не дати 6+ GB RAM, має свої латенсі із транзакціями і т.д. Її тюнінг — це взагалі невідома земля та вимагає специфічних знань та досвіду, при чому всеодно виходить, що оренда серверів дорожча за класичну реляційну базу, на звичайних дешевих 2GB RAM нодах вона працювати категорично відмовляється. Big Table — чудова коли у вас дуже проста модель данних яка лягає лише на одну таблицю, в яку ви часто пишете, але рідко читаєте. Будь які складні моделі, наприклад іерархія співробітників на підприємстві разом з тим каталог скидочних купонів — і у вас неприємності.
граф оріентовна БД, на тюнінг часу якої ніби то можна не витрачати часу
графова модель кал рідкісний, крім перформанса навіть
Проблема з носкл ще й в тому, що реляційна модель — індустріальний стандарт і людей які вчать цю модель і субд, більше в сотні раз.
А коли нада пошукати спеца який вкурить що там складного накручено з neo4j і зробить фічу — гуд лак. В найкращому випадку буде довше розбиратись
Тому графові дб — штучні кейси. Це блін як скала для джавістів. Написати щось можна, а от підтримувати треба потім почесатись
Інші моделі носкл принаймні простіше вкурити новачку. Ментальна складність нижча. Думаю саме це зіграло роль що графові це екзотіка — що недостатньо індусів які вчать графи як слід )
З точки зору e Commerce — вона дуже цікаво виглядає, позаяк скажімо каталог товарів — це ієрархічна структура данних типа — дерево із вузлами каталог-категорія-підкатегорія-товар-товарна позиція, в яку рідко пишуть — але дуже часто читають та роблять пошук.
Щось підказує що каталог товарів це зовсім не use case для графових баз,а классичний кейс для lucene похідних технологій(котрий буде перформормити для каталогу товарів і разів
аталог-категорія-підкатегорія-товар-товарна позиція
називається фасетом(атрибутом), і моделювати це через edge у графі дуже дивно(скоріше за все це і причин проблем з використанням ресурсів).
По графовим як мінімум там де є графи з різного типу edges, ієрархіями vertics різного типу і необхідності пошуку по атрибутам кожного як мінімум на декларативних графових мовах буде біль зрозумілою і скоріше за все лаконічнішою, аніж робота с рекурсивним cte в рсубд.
Big Table — чудова коли у вас дуже проста модель данних яка лягає лише на одну таблицю, в яку ви часто пишете, але рідко читаєте. Будь які складні моделі, наприклад іерархія співробітників на підприємстві разом з тим каталог скидочних купонів — і у вас неприємності.
якби у мене була ієрархія проста яке влізе в ресурси одного сервака ок може я і взяв би реляційку, якщо ні — то у вас неприємості з реляційкою як раз, у той час як neo4j наприклад(судячи по доці — може нативно виконвути cross shard queries).
В цілому описані вами use cases годні хіба щоб робити висновки про зручність використання технологій у ваших конкретних умовах як бачите.
Так ваш висновок якраз в тему. Нема універсальних технологій які для усього супер-дупер і тепер треба усе кидати і срочно переробляти усе на новітню технологію, щойно винайдену. Тобто то що називається хайпом, мода на технологію. Хоча позитивний плюс усіх хайпів та мод — вихід зі стагнації, та однобоке тлумачення, догматика. Подекуди, а скажімо для корпоративного софту, для переважної більшості випадків найкраще підходить саме реляційна модель зберігання данних, та є ціла низка випадків, де реляційна модель данних зовсім не підходить. Найбільша помилка інженера, це робити не по уму з науковим підходом дослідження, замірюваннями і т.д. — а «як усі» тобто впасти в догматику. Зазвичай будь який хайп так і розкручується.
Подекуди, а скажімо для корпоративного софту, для переважної більшості випадків найкраще підходить саме реляційна модель зберігання данних, та є ціла низка випадків, де реляційна модель данних зовсім не підходить.
корпоративний софт це не якийсь вузький кейс — а величезний сегмент з морем різних потреб. популярна не стільки реляційна модель, скількі інструментарій який надають реляційні бази данних для покриття широкого кола потреб, які іноді протирічять базовим положенням реляційної теорії.
моделювати persistance відштовхуючись від нормалізації по дефолту там теж немає потреби, а навпаки — будет потребувати більше часу на розробку можливо навіть у переважній більшості задач які є в энтерпайзі, треба завжда пам’ятати що розкласти все по ячейкам табличок ще коли їх багато не дається за безкоштовно, ні як з точки зори швидкості розробки, пітримки так і перформансу. найшвидший варіант який покриє переважну більшість середньостатистичних вимог і очікувань від апки буде мати куди більшу кількість попередніх варіантів для persistance ніж нормальні форми.
Я в своей жизни ни разу не использовал NoSQL, весь хайп прошел как-то мимо, расскажите, NoSQL вообще живо или уже сдохло?
Продолжай дальше сидеть со взрослыми зарабатывающими людьми на Оракл/Скл Сервер и не обращай на тупых детей внимание.
Я з
Та й до того в цирку їх не було.
Касандра, крута коли потрібно робити дуже багато вставок та щей репліка, еластік це фулл текст серч, редіс це кеш, сорян за русню але клікхаус для ріал там обчислень якихось значен...Ти прикалуєшься? Коли навантаження на базу починають рости дуже сильно і один інстанс не витримує то данні росповзаються бо різним базам, по різним потребам, скл це коли важливі констрейни та транзакційність...Короч візьми книжку якусь почитай по базам.
Я в своей жизни ни разу не использовал NoSQL
та то ти просто не старався
шо навіть kv-store нє?
memcached, redis, elasticsearch зара мабуть стирчать ледь не з кожної дірки
vault/consul?
tsdb теж, але то впринципі більше в області девопс-тулз всетаки
Просто я программист, а не вебмакака
Это не отличие, а общее, т.к. вебмакаки с носкл не взаимодействуют
шо навіть kv-store нє?
Не
Разве шо пет проекты
Кому это надо если можно поставить нормальный постгрес и не парить друг-другу мозги?
Нууу пока джойнів хватає на першу тисячу запитів в сек то мабуть нікому
Питання тут чи є бюджет на переписування всього коли перевалює за ;)
Сервери не резинові, вертикально можна рости постільки поскільки
Загалом я прихильник підходу використовувати на старті те в чому почуваєш себе комфортно, та хоч бля фортран якщо тобі 70ть в бороді але фортран заходить — а як злетить то можна й переписати. І не люблю всі ці ускладнення на старті теж, як і мікросервіси. Як би не старався на початку, архітектуру доведеться викинути пару раз на помийку. Так шо нмсд починати треба з джойнів таки
З такої колокольні то да ти прав, якщо щось путнє, то потім можна інвестора знайти й він на переписування грошей дасть
Стартап-кладовище все таки повне мікросервісних архітектур, і нахуя ото було старатись )) так що ти прав теж
поставить нормальный постгрес и не парить друг-другу мозги
=>
вебмакака
Вобще я тобі скажу що мабуть 90% кейсів воно й не треба всіх ускладнень
Просто всі думають що вони роблять наступний нетфлікс. Я б сказав у цьому причина
Але багато кейсів в архітектурі просто краще заходять в nosql, той же кеш чи kv
Якщо кеш брати, то все таки тримати кеш результатів з БД в самій БД — це якось ну дуже кучеряво )
А допустім гарячі якісь каунтери чи гарячі розподілені локи краще в kv складати ніж вбивати БД апдейтами
Кста поки тут нічого робить, то згадав колись якийсь чел агітував що дб для початку взагалі не треба, а досить писати в файли серіалізовані структури з пам’яті для персістенс. Згадав бо мені воно кришу зірвало тоді. Шукав правда статтю ту і не згадав як називається
За його релігією починати тре взагаліто не з джойнів, а з болота блобів які зразу грузяться в пам’ять без всяких схем і фреймворків. Ну і потім просто серіалізуються назад.
Як хтось щось подібне десь бачив і згадав де — буду вдячний за силку
Давно було, я давно не кодю на повний день, але я тоді залип в цю темку і трохи покодив для kryo, тільки через цей kryo оце і нагадався. Ідея скажена, але сенс в такому підході є, особливо для MVP
С одной стороны, такой подход кардинально повышает производительность, а с другой стороны — теряются наработанные данные при аварийном завершении приложения, тоже думал над этим. Там можно исключить не только всякие select-join и вложенные трёхэтажные выборки, которые в свою очередь являются результатом плохо спроектированной БД. Но и вообще убрать прослойку, обслуживающую всю эту запись и чтение. А серилизовать можно и в БД.
Точно саме вона, блін я думав це десь у дикому англійському інтернеті а не на доу
Дякс!
Кста поки тут нічого робить, то згадав колись якийсь чел агітував що дб для початку взагалі не треба, а досить писати в файли серіалізовані структури з пам’яті для персістенс
Это называется Data-driven Development, когда мы отказываемся от абстрагирования данных и делаем зацепление между форматом данных на диске, в памяти и в процессе обработки. На больших данных — сильно ускоряет.
Это называется Data-driven Development
Ідея не в том з якого кінця моделаювати домен чи яким подходом робити архітектуру, а в тому щоб на ранньому старті не менеджити цілий лейер баз даних
Проблема тут ще й в тому що для крім ну зовсім найпростіших кейсів це в мене виходило навпаки складніше, бо ідея бд вбудована дуже глибоко в наш айтішний моск і ми багато функціоналу отримуємо з SQL включно з acid, не помічаючи. Той же group by чи агрегація по запиту.
З файлами всього цього нема. То я погрався поколупався й так і закинув
Ну і плюс потім всеодно треба викидати і писати по людськи
Нмсд починати тут краще з якогось sqlite таки а бенефіти від екзотичного підходу ефемерні й короткоживучі
До речі зара це має бути простіше!
Щось мені каже що як замість файлів і бд взяти якийсь пандас чи аналог для яви, то можна красиво робити mvp без бд в датафреймах
Оце блін ідея в голові засіла, свербить уже спробувати )
Просто тобі не нравиця як воно горить. Люди бігають, суєтятца.
NoSQL хайп матеріалізувався у звичайні не хайпові продукти.
Ну і проекти починається з постгресу, усім іншим обростає по мірі розвитку.
Хоча ще іноді реально зустрічаються проекти на два з половиною користувача і десяток тисяч записів у базі, у які умудрилися запхнути одразу монгу, редіс та еластіксерч (реальний кейс)
Хоча ще іноді реально зустрічаються проекти на два з половиною користувача і десяток тисяч записів у базі, у які умудрилися запхнути одразу монгу, редіс та еластіксерч (реальний кейс)
Отож. Сам фигею, когда на стартапах на этапе МВП вместо простых и дешевых тулзовин, сразу кидают кровавый энтерпрайз с микросервисами
NoSQL хайп закончился?
Хайп можливо. По факту вони вже увійшли в мейнстрім.
Дінамо — в багатьох амазон проектах.
БігКвері — в гуглклауд проектах, для деяких проектів вона причина переїзду на гуглоклауд.
Редіс — стандарт для кешування, окрім того популярна у всіляких ігрових проектах і не тільки.
Монго — відсоток не скажу, але це десятки відсотків, а не одиниці.
Афіна/Хбейс та інші бігдата бази — живі, бо їм альтернативи немає.
Касандра наче здулась, але це дуже суб’єктивно і не факт (в попередньому коменті її згадали як мінімум).
Графові БД — це те що не взлетіло.
По факту вони вже увійшли в мейнстрім
Скорее они ушли в нишевую область и не отсвечивают.
А в нормальных проектах все гоняют джоины во все стороны
Нормализация — это про консистентность в первую очередь
Когда данные разлазятся по кластерам,репликам,партициям то косистентность это свосем другое, чем ключи между таблицами, и сиквел уже там как раз заметно реже используется, потому что многие функции перекладывается уже на уровень распределенного приложения, которе не может выполняться на одном компьютере.
Вобщем почитай за масштабировние и тогда поймешь зачем те или иные базы созданы.
Скорее они ушли в нишевую область и не отсвечивают.
А в нормальных проектах все гоняют джоины во все стороны
А ви точно архітектор? :)
Ще раз: Динама, Редіс, Монга — це бд «загального призначення», на них роблять все від кошика в інет магазині до ХФТ (тут ще усілякі КДБ+ і вертіка для налітики полізуть).
НоСКЛ — це найпростіший спосіб адресувати скалабіліті та перформанс в багатьох випадках.
І щоб не плодити коментарі:
Нормализация — это про консистентность в первую очередь
Констрейнти — це про консистентність. Нормалізована БД без констрейнтів, не закриє консистентність.
Нормалізація — це якраз багато в чому про перформанс, за рахунок зменшення об’ємів даних.
Знову ж, джоіни на розподілених системах без колокації всіх даних, що приймають участь у джоіні — це смерть швидкодії, а в умовах клаудів, ще і суттєве збільшення ціни (трафік, потужніші інстанси).
Ты бы не прошел у меня собес
Ты бы не прошел у меня собес
Який жах ©
Ну він в приницпі прав, нормалізація це шошо але точно не про
це якраз багато в чому про перформанс, за рахунок зменшення об’ємів даних.
Нормалізація більше властива всяким DWH і найкривавішим ентерпрайз системам
Загалом модно частково жертвувати нормалізацією щоб отримати перформанс і скалабіліті. NoSQL це по суті і є NoNormalization
Але в іншому абзаці ти про це й пишеш, то здається просто тут якесь непорозуміння в словах і виразах
You’re hired! :)
але
Констрейнти — це про консистентність
Upd набрехав сам, точно так як пишеш
В DWH денормалізація
В DWH денормалізація
Тут сильно залежить від організація ДВХ і від архітектора.
Для багатьох випадків ви праві.
Але іноді трапляються трохи інші ситуації. Наприклад, 1 раз бачив ДВХ:
— основні бази нормалізоване по НФ5 (вони казали, що то навіть доменно-ключова)
— а потім купа денормалізваних мартів
Але там відповідність регуляціям (окрім безпеки, ще всілякі бізнес контіньюті і тд) і тд була важливіша за будь-які бабки
основні бази нормалізоване
Да, я в принципі не дба і просто був на проекті де ми саме таким і займались ще за царя гороха
Набрехав я, визнаю чесно, він таки прав
В DWH денормалізація
Йеп, прав, пора мені перестать бухать і на рефреш. А нам треба такі як ти! Але це таки ще залежить від dwh
А ви точно архітектор? :)
Теж питаю себе
Мабуть устал років 20 тому )))
все гоняют джоины во все стороны
і як там у вашому стартапі з перформансом кхм тих джойнів і tps? Ваш мейнфрейм скорее жив или полужив у піковий час? :)
Графові БД — це те що не взлетіло.
амінь, той же neo4j просто жахіття devex
як і з більшістю інших технологій, хайп закінчився, всі розібрались, де треба використовувати, а де ні, і мовчки працюють.
Cassandra, Redis, Etcd они везде, значит не сдохло, как воздух — даже не замечаем, но оно есть
войсчат про автоматизоване тестуваннясьогодні о 19:00
Олександр Корж
Bogdan Shyiak
Олександр Мощенко
Alexandr Gavriluk
Олександр Мощенко
Алексей Алексей
Victor Gubin
Roman Pavlyuk
Andy W
Alexandr Gavriluk
Борис Махно
Дмитро
Bot Bot
Олексій Хількевич
Valeriy Shvets
Victor Gubin
Дмитро
Андрей Литвинов
Roman Pavlyuk
Bot Bot
Олексій Хількевич
Vadim Kopanev
schwarzlichtbezirk
Jan Haring
Otak
Bogdan Shyiak
Herman
Victor Musienkо
johnwalsh1
Найкращі коментарі пропустити