Apple представила нове покоління iPhone, включно з надтонким смартфоном iPhone 17 Air

[yuriy_dd]

Ти ж якось наповнив свою структуру

ну розмір структури - може бути сильно більше ніж навіть обєм доступною РАМ. Воно на диску собі збережене, і чекає коли за ним звернуться (або й не звернуться)
і структура - це в мене аля індекс, з яким я дуже швидко працюю - на порядки скоріше ніж робота з кешом (скажімо в 100,000 раз скоріше)

і ще - а що класти в кеш? всі варіанти результатів запитів з всіма можливими наборами brand_id і номером сторінки?

Відправлено через 37 секунд:
і таких структур - багато. Десятки.

Відправлено через 5 хвилин 48 секунд:
ще може бути - наприклад статистика - це таблиця на млрд рядків кожен десь на 20 дійсних полів
і оновлюється пару раз на добу

коли це було в мене в таблиці - то повне оновлення займало тиждень, при чому воно тримало транзакцію (бо дані мають бути станом на дату початку оновлення) і вся база пухла, к-ть запису на диск - вимірювалась сотнями терабайт
доводилось оновлювати лише малу активну частину, цілісність даних була порушена - жах був
зараз - повне оновлення займає 54хв, запису на диск - до 200 Гб

[Scoffer]

yuriy_dd
column-oriented бд зроблять тобі щастя

[yuriy_dd]

column-oriented бд зроблять тобі щастя

не зробить, для того щоб зрозуміти - потрібно розуміти скільки байт фактично читається з диску - якщо ви читаєте 1 байт
а тепер якщо треба прочитати 5 колонок того самого рядка - треба зробити читання з 5-ти місць як мінімум

розумієте? маєте такий досвід?

[Sanьka]

життя - це суцільна математика, логіка і тд
навіть рецепт - це алгоритм

Все це йде під три чорти, якщо людина не взмозі осмислити все вєлічіє М4

[Scoffer]

yuriy_dd
Ти якусь фігню розповідаєш.
Традиційні RDMS зберігають дані в вигляді сторінок приблизно от такого формату:

спойлер

Це постгре, але інші +/- схожі. Де строка займає рівно стільки байтів, скільки треба для зберігання типів даних цієї строки. Ні байтом більше, ні байтом менше. При цьому RDMS ніколи(!) не працює з даними з диску напряму, а спочатку підвантажує їх з гранулярністю в сторінку в оперативу. Це стандартний випадок.
Якщо треба менше читати з диску ціною того що складніше оновлювати? Ноу проблем, береш колоночну бд, котра замість строк отам тримає пожаті колонки, а колонки гарно стискаються, заради чого і все оте. Якщо треба щоб дані знаходились в пам'яті до того як пройшов запит по ним то береш інмеморі бд і налаштовуєш одну з багатьох стратегій префетча і політику вивільнення з пам'яті якщо її не вистачає. А можна і поєднати, є RDMS котрі одночасно колоночні і інмеморі. На кожен випадок все давно вигадано, просто береш підходящий інструмент і використовуєш.
Судячи з твоїх слів ти просто повторив індекс умовного постгре, котрий чомусь у тебе в сто тишь раз швидше працює. Ага, зараз.

[Bender911]

я брал гармин ради оффлайн карт которые работают автономно где нету сети и всяких фич для велосипедистов типа построения маршрутов по картам активности. А зачем вот apple watch я вообще не понимаю - если это просто копирования всех функций на телефоне и плюс еще геморрой с автономностью.

Ви як раз та категорія, що я описав - карти, велосипед. Я б теж брав Гармін якби десь по хащам бігав.

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

Не тільки залі: дійсьно зрочно бачити і спортивні показники, і швидко додати в улюблені пісню в Spotify, і листа прочитати поки кудись біжиш і не хочеш брати в руки телефон, наприклад в зимку, в сумці лежить.

[yuriy_dd]

Традиційні RDMS зберігають дані в вигляді сторінок приблизно от такого формату:

так

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

плюс службова інформація, яка займає досить місця, навіть якщо fillfactor = 100
якщо почати оновлювати - пухне дуже швидко

При цьому RDMS ніколи(!) не працює з даними з диску напряму, а спочатку підвантажує їх з гранулярністю в сторінку в оперативу

так, навіть якщо потрібно 1 байт даних. Тому якщо доступ до даних випадковий - то читати треба багато, і часто краще просканувати всю таблицю ніж доступатись по індексу - оптимізатор так часто і робить, але люди дивуються чому обраний Sequential Scan план виконання

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

але воно не буде менше читати. Бо якщо рядок даних у випадку Постгре - читався один раз - бо всі значення на одній сторінці даних, то тепер треба зачитати значення для 5-ти колонок того самого рядки з різних місць

котра замість строк отам тримає пожаті колонки, а колонки гарно стискаються

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

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

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

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

індекс - це як мінімум дерево B-tree. Гілки дерева зберігаються по сторінкам, доступ до них - теж має проблему random read
в мене зовсім інші структури - оптимізовані для мінімізації читання = вирішують проблему random read

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

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

звожу задачу random read до linear read

Відправлено через 1 хвилину 38 секунд:

Все це йде під три чорти, якщо людина не взмозі осмислити все вєлічіє М4

а ви в змозі осмислити що одно-потік у М4 на 50% швидший за одно-потік у останього проца від АМД?
ви знаєете за покоління на скільки зростає швидкість одно-потоку?
скільки потрібно поколінь щоб стало +50% ?

[der_meister]

начали за аппле, перешли к базам данных.... капец.

[dead_rat]

начали за аппле, перешли к базам данных.... капец.

Не подобається, то зараз перейдемо на Трампа, політику і геїв.

Відправлено через 6 хвилин 6 секунд:
yuriy_dd

Доречі, ви часом на Доу не пишете? Хоч і про секьюріті, але відчувається ніби ви писали

https://dou.ua/forums/topic/52469/

[Васильович]

Хоч і про секьюріті, але відчувається ніби ви писали

То ж там немає згадок М4

[yuriy_dd]

Доречі, ви часом на Доу не пишете? Хоч і про секьюріті, але відчувається ніби ви писали
https://dou.ua/forums/topic/52469/

подібним колись займався, але це не я

[dead_rat]

yuriy_dd
Доречі, чат гпт каже, що це лише Постгрес не може автоматично оновлювати матеріалізед вью. А от Оракл та MS можуть.

[yuriy_dd]

Доречі, чат гпт каже, що це лише Постгрес не може автоматично оновлювати матеріалізед вью. А от Оракл та MS можуть.

може, я не знаю. З Ораклом - ну дуже давно працював (можна сказати що вже й забув), з МС - відносно недавно
це платні бази, і не дешеві. Постгре - безкоштовний

але матеріалізед вью - не вирішує проблему - я описав з самого початку дуже простий приклад

ви розумієте що індекс - це свого роду матеріалізед вью? і є підтримка "index-only scan"
і оновлюється автоматично

[der_meister]

dead_rat
лучше перейдите к обсуждению, почему не выпустили 17плюс)))

но, если вы индексируете ваши бд на айфонах, то мое вам уважение

[Graveworm]

перейдемо на Трампа, політику і геїв.

А давайте

воно буде працювати швидко і не вимагатиме потужного заліза

Я, звісно, взагалі не дотичний до іт, і тим паче до сістем інжинігрінга, але, вибачте за моє дилетантське судження, у випадку нештатної ситуації одмєн залишиться наодинці зі своїми костилями. А у готового рішення є підтримка 24/7, форуми, комьюніті і всяке таке. І, мені здається, для корпоративного сектору важливіше надійність і передбачуваність, ніж самопальні рішення для домашнього сервака з проном

Відправлено через 1 хвилину 36 секунд:

автоматом підкажуть

Тобто, фонова аналітика, телеметрія та AI-slop

[dead_rat]

у випадку нештатної ситуації одмєн залишиться наодинці зі своїми костилями. А у готового рішення є підтримка 24/7, форуми, комьюніті і всяке таке. І, мені здається, для корпоративного сектору важливіше надійність і передбачуваність, ніж самопальні рішення для домашнього сервака з проном

Саме так, пане. Всі ці самописні приколи веселі, поки це твій прон чи локальний ларьок. Ви ж теж не повірили, що місцевий кулібін може написати кращій пошук, ніж доступний в усіх корпоративних БД?
Чи на крайняк він може бути швидшим, бо не покриває купу кейсів, достатньо почитати книжку по дизайну бд, щоб голова пішла кругом від кількості проблем.

От контора де я грібу, має оберт 8 мільярдів, уявляєте реалізувати щось важливе на прекрасному самописному кеші?

[daesz]

життя - це суцільна математика, логіка і тд
навіть рецепт - це алгоритм

Все це йде під три чорти, якщо людина не взмозі осмислити все вєлічіє М4

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

[Denvys5]

бо не покриває купу кейсів

Immutable database!
Full ACID!
Full CAP resolution guaranteed!

От контора де я грібу, має оберт 8 мільярдів, уявляєте реалізувати щось важливе на прекрасному самописному кеші?

Це якраз порядок цифр коли контора таки може написати щось своє. З'являється критична масса експертизи щоб пропланувати таке рішення, закриваючи діри у дизайні. Інша справа що контора може дуже швидко зрозуміти що не потягне задачу своїми силами і відмовитися вже з цієї причини.
Ось ця штука приблизно так з'явилася, з різницею що питання "потягне" було субсидійовано клієнтурою - https://solutionshub.epam.com/solution/timebase

[dead_rat]

Це якраз порядок цифр коли контора таки може написати щось своє. З'являється критична масса експертизи щоб пропланувати таке рішення, закриваючи діри у дизайні.

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

[yuriy_dd]

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

але ви ж розумієте що програмісти в принципі щось пишуть, а не використовують готові блоки
і тому ваш коментар може стосуватись будь-якого написаного коду
пс: а в принипі те що я пропоную - підтримувати може будь хто з мозгами. Додуматись - отут не факт

А у готового рішення є підтримка 24/7, форуми, комьюніті і всяке таке

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

Ви ж теж не повірили, що місцевий кулібін може написати кращій пошук, ніж доступний в усіх корпоративних БД?

я вам описав прості випадки, з якими ви би мали стикатись щоб оцінити

Чи на крайняк він може бути швидшим, бо не покриває купу кейсів

звичайно що це не загальне рішення, а лише для конкретних випадків
для загальних - є індекси

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

а ви вже на якому етапі росту? вже дійшли до денормалізації та відмови від foreign keys?
чи ще на 3-ій нормальній формі?