Olympus продовжує зростати швидше, ніж ми очікували, як і користувальницький контент. Чим більше користувачів, тим більше повідомлень в чаті. У липні ми оголосили про 40 млн повідомлень у день, в грудні оголосили про 100 млн, а в середині січня подолали 120 млн. Ми відразу вирішили зберігати історію чатів вічно, так що користувачі можуть повернутися в будь-який момент і отримати доступ до своїх даних з будь-якого пристрою. Це багато даних, потік і обсяг яких наростає, і всі вони повинні бути доступними. Як ми це робимо? Cassandra!

Читати далі →


Раніше (1, 2) ми обґрунтували і продемонстрували можливість існування
просторового індексу, що володіє всіма плюсами звичайного B-Tree — індексу та
не поступається по продуктивності індексу на основі R-Tree.
Під катом узагальнення алгоритму на тривимірний простір, оптимізації та бенчмарки.

Читати далі →



Віктор Тарнавський показує, що воно працює. Перед вами розшифровка доповіді Highload++ 2016.

Доброго дня. Мене звати Віктор Тарнавський. Я працюю в «Яндексі». Розповім про дуже швидку, дуже відмовостійку і супермасштабируемую базу даних ClickHouse для аналітичних задач, яку ми розробили.

Пару слів про мене. Мене звати Віктор, я працюю в «Яндексі» і керую відділом, який займається розробкою аналітичних продуктів, таких як «Яндекс.Метрика» та «Яндекс.AppMetrica». Я думаю, багато хто з вас користувалися цими продуктами і знають їх. Ну і в минулому і досі пишу багато коду, а ще раніше займався розробкою заліза.

Читати далі →

Google запустила бета-версію Cloud Spanner — СУБД покоління NewSQL



Google відкрила для всіх бета-версію сервісу Cloud Spanner, глобально розподіленої высокомасштабируемой мультиверсионной NewSQL БД з підтримкою розподілених транзакцій.

Кілька років Google використовувала цей сервіс виключно для внутрішніх потреб. На ньому працюють ключові системи Google, в тому числі AdWords і Google Play. Spanner — еволюційний розвиток NoSQL-попередника Google Bigtable. Сам же c Spanner відносять до сімейства NewSQL-рішень, тобто воно поєднує в собі переваги реляційних і нереляційних СУБД. Це ACID-транзакції і синтаксис SQL традиційних СУБД без шкоди для горизонтального масштабування і високої доступності, властивих NoSQL.

Виходячи з досвіду роботи системи всередині компанії, Google пропонує клієнтам аптайм 99,9999% (шість дев'яток, тобто максимум 31,5 секунди простою в рік), клієнтські бібліотеки з підтримкою Java, Go, Python, Node.js та ін

Читати далі →

Сходження дата-інженера

image

Я приєднався до команди Facebook в 2011 році в якості інженера бізнес-аналітика. До моменту, коли я залишив команду в 2013 році я вже був дата-інженером.

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

Дата-інжиніринг?
Наука про даних як самостійна дисципліна переживає період отроческого самоствердження і визначення себе. У теж час дата-інжиніринг можна було назвати її «молодшим братом», який теж проходив через щось подібне. Дата-інжиніринг приймав від свого «старшого родича» сигнали, шукав своє місце і власну ідентичність. Як і вчені, займаються обробкою даних, дата-інженери теж пишуть код. Він є высокоаналитическим, з великою часткою візуалізації.

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

Читати далі →

Просторовий індекс для PostgreSQL на основі Z-order (vs R-tree), продовження


минулий раз ми прийшли до висновку, що для ефективної роботи просторового індексу на основі Z-order необхідно зробити 2 речі:
  • ефективний алгоритм отримання подинтервалов
  • низькорівневу роботу з B-деревом
Ось саме цим ми і займемося під катом.
Читати далі →

Історія СУБД Oracle — першою комерційно успішною реляційної СУБД

image

До середини 70-х років інформація в базах даних розподілялася за старовинним ієрархічним, або «деревоподібному», принципом, який до цих пір використовується в настільних операційних системах.

Перші прототипи реляційних СУБД існували вже в 70-ті роки ХХ століття. Однак мало хто вірив у можливість добитися ефективної реалізації таких систем. Тим не менше, до кінця 1980-х років реляційні системи зайняли на світовому ринку СУБД домінуюче положення.

У зв'язку з цим багато компаній стали позиціонувати свої СУБД як «реляційні» в рекламних цілях. Але далеко не завжди вони мали для цього достатньо підстав. Тому автор реляційної моделі даних Едгар Кодд в 1985 році опублікував свої знамениті «12 правил Кодда», яким повинна відповідати кожна РСУБД.

Одним з перших прототипів реляційних баз даних була система System R. Це проект компанії IBM, який з'явився в 1976 році. Він надихнув майбутніх засновників Oracle на створення власної реляційної СУБД
Читати далі →

Асинхронна обробка запитів в СУБД в пам'яті, або як впоратися з мільйоном транзакцій в секунду на одному ядрі


Привіт! У двох моїх останніх статтях я говорив про те, як СУБД в оперативній пам'яті забезпечують збереження даних. Знайти їх можна тут і тут.

У цій статті я хотів би порушити проблему продуктивності СУБД в оперативній пам'яті. Давайте почнемо обговорення продуктивності з найпростішого випадку використання, коли просто змінюється значення по заданому ключу. Для ще більшої простоти припустимо, що серверна частина відсутня, тобто не відбувається ніякого клієнт-серверної взаємодії з мережі (далі буде зрозуміло, навіщо ми це зробили). Отже, СУБД (якщо її можна так назвати) повністю перебуває у оперативної пам'яті вашого додатка.

Читати далі →

Як уникнути стрибків по часу відгуку і споживання пам'яті при знятті знімків стану в СУБД в оперативній пам'яті


Пам'ятайте мою недавню статтю «Що таке СУБД в оперативній пам'яті і як вона ефективно зберігає дані»? У ній я навів короткий огляд механізмів, які використовуються в СУБД в оперативній пам'яті для забезпечення збереження даних. Мова йшла про два основних механізми: запис в журнал транзакцій і зняття знімків стану. Я дав загальний опис принципів роботи з журналом транзакцій і лише зачепила тему знімків. Тому в цій статті про знімках я розповім більш докладно: почну з найпростішого способу робити знімки стану в СУБД в оперативній пам'яті, виділю кілька пов'язаних з цим способом проблем і докладно зупинюся на тому, як даний механізм реалізовано у Tarantool.

Отже, у нас є СУБД, що зберігає всі дані в оперативній пам'яті. Як я вже згадував у моїй попередній статті, для зняття знімка стану необхідно всі ці дані записати на диск. Це означає, що нам потрібно пройтися по всіх таблиць і за всіма рядками в кожній таблиці і записати все це на диск одним файлом через системний виклик write. Досить просто на перший погляд. Однак проблема в тому, що дані в базі постійно змінюються. Навіть якщо заморожувати структури даних при знятті знімка, в результаті на диску можна отримати неконсистентное стан бази даних.

Читати далі →

«П'яна» база даних: як на 1 базі ми зробили 7 тестових майданчиків, причому у кожної — свій власний інкремент і діфф

Уявіть собі компанію «Ингосстрах» з продуктивною базою 30 Тб. Вона лежить на великий такий залізної хранилке, її обслуговує дуже-дуже важкий сервер. Все красиво. Тепер уявіть, що ви написали фічу або шматок функціоналу, і вам потрібно протестувати її на бойовий базі. Шматочок бази відщипнути неможливо з ряду причин.

Що ви зробите? Ну, традиційний шлях — взяти ще одну хранилку на 30-35 Тб (але дешевше раз в п'ять, повільніше і простіше, без резервування) і отреплицировать базу на неї. А потім працювати з копією. Хороший план?

Немає. Справа в тому, що коли у вас кілька команд розробки (а в нашому випадку їх кількість зросла від 4 до 10), потрібно, відповідно, від 4 до 10 тестових майданчиків. Або навіть більше. Купувати таке залізом просто нереально, тому потрібно рішення, яке дозволить один раз повторити бойову базу, а потім «відображати» її кожному серверу як окрему тестову, але зберігаючи всі зміни тестової майданчику. Ось так:



Розкажу, як на одному вузлі з фізичної базою ми розгорнули 7 тестових майданчиків, ізольованих один від одного.
Читати далі →