1.
Андрей Фролов, ведущий программист, Allods Team
БАЗЫ ДАННЫХ В ИГРАХ:
ОТ АЛЛОДОВ ДО SKYFORGE

2.
КОРАБЛИ БОРОЗДЯТ…
2

3.
ВНЕЗАПНО!
3

4.
ПАНИКА
4

5.
БЕЗЫСХОДНОСТЬ
5

6.
6
Базы данных – критическая часть
игрового сервера.
Небрежное отношение ведѐт к
катастрофе

7.
ПРОЕКТИРОВАНИЕ – ДЕЛО НЕ ПРОСТОЕ
• Надѐжность
• Производительность
• Масштабирование
• Вопросы оперирования
• Сложности в разработке
7

8.
ALLODS ONLINE
8

9.
ALLODS ONLINE
• Шарды
• 200 транзакций в секунду
• 1 тред
• MySQL
9

10.
SKYFORGE
10

11.
SKYFORGE
• Нет шардов
• 100.000+ CCU ( до 10^6 )
• 1.000 CCU ~ 30-70 tps.
• 100.000 CCU ~ 7.000 tps.
• Поменьше рисков
11

12.
МНОГО ДАННЫХ
• 10.000.000 пользователей
• 350.000.000 предметов
• 200+ ГБ
12

13.
МНОГО ПРОГРАММИСТОВ
13

14.
FREE 2 PLAY
Предмет = Время = Деньги
Транзакции
14

15.
НАШЕ РЕШЕНИЕ
15

16.
АРХИТЕКТУРА
16
Game Mechanics
DB Interface
DATABASE
DB Service

17.
SERVICE ORIENTED ARCHITECTURE
• Всѐ есть сервис. БД один из них.
• База спрятана за интерфейсом.
• Группировка функций в «паки».
• Один метод - одна транзакция.
17

18.
ВЫЗОВ МЕТОДА
18

19.
КЭШ И СИНХРОНИЗАЦИЯ
19
DB Service
Database
Operation[]
DB Interface
Spell “Fireball” выучен

20.
ПРЯМОЕ ПОДКЛЮЧЕНИЕ
JDBC
20

21.
OBJECT TO RELATIONAL MAPPING
Hibernate
getSession().save(dataSet)
21

22.
МАСШТАБИРОВАНИЕ
22

23.
ШАРДИНГ
• Шардировать по аккаунтам
• Ключ – ID пользователя
23
INNER IDDB ID

24.
VIRTUAL SHARDS
24
Шард
Шард
Шард
Шард
Шард
Шард
Шард
Шард
Шард
Шард
Шард
Шард

25.
РАСПРЕДЕЛЁННЫЕ ТРАНЗАКЦИИ
Свой велосипед на очередях
• Универсально
• Быстро
• Много кода = много багов
• Eventual consistency
25

26.
РАСПРЕДЕЛЁННЫЕ ТРАНЗАКЦИИ
Native
• Мало кода - мало багов
• Не все базы поддерживают
• Требует дополнительной прослойки
• Тормозят
26

27.
МОДЕЛЬ ДАННЫХ
27

28.
МОДЕЛЬ ДАННЫХ
Свой формат
• Читается только кодом
• Сложно конвертировать
• Перезапись только целиком
28

29.
МОДЕЛЬ ДАННЫХ
Реляционная модель
• SQL
• Constraints
• Недостаточная производительность
29

30.
МОДЕЛЬ ДАННЫХ
NoSQL
• Human readable формат (JSON)
• Поддержка типов на уровне базы
• Перезапись целиком
30

31.
МОДЕЛЬ ДАННЫХ
Гибрид
31

32.
ВЫБОР БД
• Bottleneck – диск
• Транзакции
• MongoDB, MySQL, PostgreSQL
32

33.
ВЫБОР БД
PostgreSQL лучше MySQL.
• Native распределѐнные транзакции
• Синхронная реплика
• Кастомные типы данных
• Намного меньше багов
33

34.
PERFORMANCE
Почему базы тормозят?
34

35.
НОРМАЛЬНЫЕ ЦИФРЫ
Raid 10
• 1 thread => 400 tps
• 10 threads => 2.500 tps
• Latency 2 - 30 ms
35

36.
BOTTLENECK
36
SSDHDD
Lock Lock Free
Delete Mark
Working Set < Memory

37.
PERFORMANCE VS RELIABILITY
• Модели поведения fsync()
• Синхронная репликация
SSD,Синхронная реплика,Interconnect.
Быстро и безопасно.
37

38.
ПЕРЕКРЁСТНАЯ РЕПЛИКАЦИЯ
39
DB1
DB2 Replica
Shard 1
DB2
DB1 Replica
Shard 2

39.
ЭВОЛЮЦИЯ АЛЛОДОВ В SKYFORGE
40

40.
ALLODS ONLINE
• Шардинг
• JDBC/ Hibernate.
• 1 база на 1 шард.
• Общие базы: Биллинг, Аккаунт.
• Распределѐнные транзакции вручную.
• Нет единого интерфейса.
41

41.
ALLODS ONLINE
• MySQL, Гибридная схема
• Raid.
• fsync асинхронный c паузой в 1 сек.
• 200 tps.1 тред.
42

42.
ОПЕРИРОВАНИЕ ALLODS ONLINE
• Логи в читаемом виде. Возможен grep.
• Админы знают, легко оперировать.
• Проблемы при обновлении схемы.
• Реплика отваливается.
43

43.
SKYFORGE
44

44.
SKYFORGE
• 100.000 CCU
• Hibernate
• 15+ баз в реалме.
• Native распределѐнные транзакции.
• Единый интерфейс к БД.
45

45.
SKYFORGE
• PostgreSQL
• SSD
• fsync синхронный
• Cинхронная реплика
• Virtual shards
• 1 тред x 15+ раз
46

46.
СУХОЙ ОСТАТОК
• SOA
• Virtual Shards
• Hibernate
• SSD
• PostgreSQL + гибридная модель
• Backup
47

47.
ВОПРОСЫ
48
Андрей Фролов
Ведущий программист
a.frolov@corp.mail.ru