Как мы сбежали от PostgreSQL или когда реляционная БД не справляется

Доклад на Конференцию "Стачка"
Большое количество данных - это здорово. Сложная бизнес логика - интересно. Работает быстро - прекрасно! Выкинешь какой-нибудь пункт - идеально. Расскажу о том, что случилось, как решали проблемы и к чему, в итоге, пришли.

Transcript

2. 2 @zzetorg
3. ÏПËЛÀАÒТÔФÎОÐРÌМÀА ÄДËЛßЯ ÑСÎОÇЗÄДÀАÍНÈИßЯ ÈИ ÏПÐРÎОÑСÌМÎОÒТÐРÀА ÊКÎОÐРÎОÒТÊКÈИÕХ ÇЗÀАÖЦÈИÊКËЛÅЕÍНÍНÛЫÕХ ÂВÈИÄДÅЕÎО ÄДÎО 10 ÑСÅЕÊКÓУÍНÄД ÄДËЛÈИÍНÍНÎОÉЙ 3
7. — N миллионов записей — Взять из них 10 записей — Подготовить JSON — Отправить пользователю 7
8. + 8
9. — Большой JSON ~140 Kb — Нетривиальная выборка — Записи обновляются часто — Tree — Нет старого контента 9
11. 11 Erotica Banned Private Friends only Copyright Subscription … etc.
12. 12 0 175 350 525 700 1 10 20 40 50 100 200 300 500 700 1000 t, ms follows
18. SELECT * FROM coubs LIMIT 10; SELECT * FROM coubs LIMIT 10 OFFSET 10; INSERT INTO coubs ........; SELECT * FROM coubs LIMIT 10 OFFSET 20; 18
19. SELECT * FROM coubs LIMIT 10; SELECT * FROM coubs LIMIT 10 OFFSET 10; DELETE FROM coubs WHERE ........; SELECT * FROM coubs LIMIT 10 OFFSET 20; 19
20. SELECT * FROM coubs LIMIT 10; SELECT * FROM coubs LIMIT 10 OFFSET 10; UPDATE coubs ........; SELECT * FROM coubs LIMIT 10 OFFSET 20; 20
21. — Большой JSON ~140 Kb — Нетривиальная выборка — Записи обновляются часто — Tree — Нет старого контента 21
22. — Большой JSON ~140 Kb — Нетривиальная выборка — Записи обновляются часто — Tree — Нет старого контента 22
23. SELECT * FROM coubs ORDER BY key LIMIT 10; SELECT * FROM coubs WHERE key < ... ORDER BY key LIMIT 10; INSERT INTO coubs ……..; SELECT * FROM coubs WHERE key < ... ORDER BY key LIMIT 10; 23
24. SELECT * FROM coubs ORDER BY key DESC LIMIT 10; SELECT * FROM coubs WHERE key < ... ORDER BY key DESC LIMIT 10; DELETE FROM coubs WHERE ...; SELECT * FROM coubs WHERE key < ... ORDER BY key DESC LIMIT 10; 24
25. SNAPSHOT (CACHE) 25
26. — Нужно хотя бы 1 раз сгенерировать — Нужно где-то хранить — Нужно как-то актуализировать 26
27. — Нужно хотя бы 1 раз сгенерировать — Нужно где-то хранить — Нужно как-то актуализировать 27
28. Page 1: делаем копию доступных данных Page 2: работаем с данными из копии Page 3: работаем с данными из копии 28
29. — Нужно хотя бы 1 раз сгенерировать — Нужно где-то хранить — Нужно как-то актуализировать 29
31. Page 1: делаем копию доступных данных Page 2: работаем с данными из копии 31
32. — Нужно хотя бы 1 раз сгенерировать — Нужно где-то хранить — Нужно как-то актуализировать 32
33. Page 1: делаем копию доступных данных Page 1: добавляем новые записи Page 2: работаем с данными из копии 33
34. Генерация первого набора - долго Достройка кеша - долго* * при редких посещениях 34
35. ÎОÏПÒТÈИÌМÈИÇЗÈИÐРÓУÉЙ SQL 35
36. 36 — Берем все кобы, которые попадают в подписки — Среди этих кобов ищем дублирующиеся рекобы — Выкидываем их, оставляем только первые — Выкидываем все то, что не должно быть видно ÁБÛЫËЛÎО ÊКÀАÊК-ÒТÎО ÒТÀАÊК
37. 40 000 600 Несколько запросов 1 запрос ms 37 ms
39. 39 502
41. ×ЧÒТÎО ÄДÀАËЛÜЬØШÅЕ? 41
42. ÏПÎОËЛÓУ×ЧÅЕÍНÈИÅЕ ÄДÀАÍНÍНÛЫÕХ ÏПÀАÐРÀАËЛËЛÅЕËЛÜЬÍНÎО 42
45. 45 ÎОÒТÄДÅЕËЛÜЬÍНÛЫÉЙ ÑСÅЕÐРÂВÈИÑС
46. 46 Write: — New coub / recoub — Follow Read: — Page + PerPage = [ids]
48. 48 ÏПÎО×ЧÅЕÌМÓУ ERLANG?
49. HOW IT WORKS 49
50. FRONTEND SERVERS DATABASE SERVERS TIMELINE SERVER BACKEND SERVERS 1 2 3 4 5 6 0.02-2ms 1.5——-–2ms ~200-500ms 50
51. FRONTEND SERVERS DATABASE SERVERS TIMELINE SERVER BACKEND SERVERS 1 2 3 2 3 4 äдîо 5 ìмèи… 0.05 - 5ms 51 4 5
52. 52 api workers workers hot data fetch worker data refresh worker update worker immediate workers workers
53. 53 hash table record user_id integer coub_ids list tech_data integer/binary hash table record user_id integer coubs record tech_data integer/binary hot data data
54. ÏПÎО×ЧÅЕÌМÓУ ÂВÑСÅЕ ÒТÀАÊК ÏПÎОËЛÓУ×ЧÈИËЛÎОÑСÜЬ? 54
55. @zzetorg