Основы проектирования архитектуры данных | Кодементор

Что охватывает это исследование

Куда попадают данные аутентификации пользователя? А как насчет нашего регулярно читаемого контента? Как насчет изображений и регулярно обслуживаемых файлов?

Это исследование предназначено для того, чтобы упростить для архитектора данных принятие решения о том, куда должна идти каждая часть данных в его / ее проекте, принимая решения, основанные на сильных и слабых сторонах каждой БД. Он предназначен для упрощения процесса принятия решений архитектором программного обеспечения при разработке новой архитектуры данных для проекта.

Что не охватывает данное исследование

Сколько это будет стоить? Могу ли я найти разработчиков, которые смогут реализовать мой дизайн? Сколько данных может обрабатывать этот дизайн? Как я могу контролировать эффективность моего выбора?

Это исследование не охватывает стоимость, простоту внедрения или размер данных в выбранных базах данных.

Если ваш проект небольшой, было бы лучше придерживаться одной базы данных, поскольку все они способны очень эффективно обрабатывать до 105 записей данных. Как только этот порог превышен, вы должны начать искать способы сделать его более эффективным.

Мониторинг не рассматривается в этом исследовании, так как это отдельная тема, и каждая реализация требует отдельного рассмотрения. Просто имейте в виду, что если вы настроите правильные индексы, БД редко будет первым виновником проблем с эффективностью.

Тесты производительности в существующих исследованиях

Я основывал свои решения на следующих документах и ​​статьях
2017: статья Microsoft Azure «NoSQL против SQL» (ссылка на сайт)

2014: «Оценка производительности баз данных NoSQL: пример» (ссылка на сайт)
Джон Клейн, Йен Гортон, Нил Эрнст, Патрик Донохью
Институт программной инженерии
Университет Карнеги Меллон
Питтсбург, Пенсильвания, США
{jklein, igorton, nernst, pd}@sei.cmu.edu

Ким Фам, Крисьян Мацер
Центр исследований телемедицины и передовых технологий
Командование медицинских исследований и материалов армии США
Фредерик, доктор медицины, США
kim.solutionsit@gmail.com, cmatser@codespinnerinc.com

2013: «Сравнение производительности баз данных SQL и NoSQL» (ссылка на сайт)
Ишан Ли и Сатиамурти Манохаран
Департамент компьютерных наук
Оклендский университет
Новая Зеландия

Общие соображения по проектированию архитектуры данных

1. На этапе проектирования измеримые и неизмеримые показатели влияют на выбор, который мы делаем для оптимизации эффективности услуг.
   Измеряемые показатели:
   а. Вызовы, которые каждый API делает в БД
   б. Количество сложных запросов в API
   в. Количество операций записи и чтения, выполняемых каждым API.
   Неизмеримые показатели:
   а. Частота каждого API
   б. Будет ли нагрузка на БД увеличиваться медленно или скачкообразно
   в. Влияние операций блокировки данных на эффективность системы

2. Их можно обнаружить только с помощью мониторинга, но они останутся ненадежными, поскольку будут зависеть от усредненных данных, которые будут меняться ежедневно.

3. Откуда большая часть задержки? БД, веб-сервер или сторонние API
   Вызовы стороннего API будут медленнее, чем функции БД или веб-сервера, и могут быть оптимизированы только в том смысле, что их можно ставить в очередь и вызывать асинхронно.

4. Отчеты значительно замедляют работу всей системы, поскольку их часто очень сложно извлечь для анализа, и они потребляют большую часть ресурсов системы. Отчетные данные всегда требуют специальной обработки, чтобы ограничить их влияние на производительность системы в целом, и почти всегда предназначены для чтения.

К счастью, нам больше не нужно выбирать только одну базу данных для хранения всех наших данных. Основными типами являются базы данных SQL и NoSQL, но различные доступные бренды сильно различаются. Добавьте к этому различные варианты развертывания для каждой БД, такие как Master-Slave, репликация, сегментирование и сервисы, подобные Hadoop, среди прочих, и вы получите множество вариантов для принятия решения о том, какие данные куда направляются.
Варианты SQL: MySQL, Postgres, MariaDB, Oracle, SQL Server
Разновидности NoSQL: Couchbase, CouchDB, MongoDB, Cassandra, Azure DocumentDB и HBase.

Шкала

Строго говоря, вам придется очень тщательно продумать все параметры вашей БД, и почти все правила выходят за рамки, когда речь идет об очень больших наборах данных. Эта таблица — всего лишь начальная стратегия для определения основы вашего дизайна.
Важно следить за производительностью и иметь возможность сравнивать и тестировать различные конфигурации, чтобы, когда эффективность начнет падать, у вас были разумные альтернативы всей этой панике! Я рекомендую проводить не более 5 базовых нагрузочных тестов, которые измеряют задержку вашей системы на ее основных функциях при значительной нагрузке. Например, множество пользователей пытаются войти в систему одновременно или множество пользователей пытаются одновременно заблокировать 1 запись.

Вопросы об измеримых показателях

Ответьте на следующие вопросы для вашего собственного проекта. Я отвечу на них позже в разделе моего собственного проекта.

1. Каков процент запросов, выполняющих сложные запросы?
2. Каков процент запросов, выполняющих простые запросы?
3. Каков процент запросов, которые блокируют таблицы?
4. Каков процент запросов на вставку/обновление/удаление из одной таблицы?
5. Каков процент запросов на вставку/обновление/удаление из нескольких таблиц?

Сценарии БД для тестирования

Следующие тестовые примеры следует запускать в тестовой среде, аналогичной ожидаемой рабочей среде. Примеры написаны для MySQL.

Размер исходных данных должен соответствовать ожидаемому количеству записей для текущей архитектуры.

Наконец, им нужно пройти через ваш серверный код, а не только в БД для получения более реалистичных результатов.

1. Запрос 1 записи в одной таблице. например:

SELECT * FROM User LIMIT 1;

2. Вставьте 1 запись в одну таблицу. например:

ВСТАВИТЬ В Пользователя (Name, email) ЦЕННОСТИ («Том Харди», «tom@hardy.com»);

3. Запросить несколько таблиц в одном запросе для 1 записи. например:

ВЫБРАТЬ *
ОТ пользователя u
ПРИСОЕДИНЯЙТЕСЬ к предпочтениям p ON p.UserID=u.ID
ПРИСОЕДИНЯЙТЕСЬ к UserImage ui ui.UserID=u.ID
ПРИСОЕДИНЯЙТЕСЬ к изображению i ON i.UserID=u.ID
Блок JOIN b ON b.PreferenceID=p.ID;

4. Запрос на 10 000 записей. например:

SELECT * FROM User LIMIT 10000;

5. Запрос 10 000 записей из 4 или более таблиц. например:

ВЫБРАТЬ *
ОТ пользователя u
ПРИСОЕДИНЯЙТЕСЬ к предпочтениям p ON p.UserID=u.ID
ПРИСОЕДИНЯЙТЕСЬ к UserImage ui ui.UserID=u.ID
Блок JOIN b ON b.PreferenceID=p.ID
ПРЕДЕЛ 10000;

6. Запросите несколько таблиц в одном запросе с индексированными и неиндексированными критериями для 1 записи. например:

ВЫБРАТЬ *
ОТ пользователя u
ПРИСОЕДИНЯЙТЕСЬ к UserPreferences p ON p.UserID=u.ID
ПРИСОЕДИНЯЙТЕСЬ к UserImage ON ui ui.UserID=u.ID
ПРИСОЕДИНЯЙТЕСЬ к изображению i ON i.UserID=u.ID
Блок JOIN b ON b.PreferenceID=p.ID
ГДЕ u.email=’tom@hardy.com’ (проиндексировано)
И p.InterestID=5 (индексировано)
И p.CreationDate=’14/10/2016′ (без индекса)
И б.Состояние=2; (без индекса)

7. Вставка в несколько таблиц. например:

ВСТАВИТЬ В Пользователя (Name, email) ЦЕННОСТИ («Том Харди», «tom@hardy.com»);
ВСТАВИТЬ В Настройки (Name, UserID, State) ЦЕННОСТИ («Продукты», 12, 1);
ВСТАВИТЬ В ИЗОБРАЖЕНИЕ (Name, Source) ЦЕННОСТИ («Телец», «

8. Запросить несколько таблиц для 1 записи и вставить в другие таблицы. например:

ВЫБРАТЬ *
ОТ пользователя u
ПРИСОЕДИНЯЙТЕСЬ к предпочтениям p ON p.UserID=u.ID
ПРИСОЕДИНЯЙТЕСЬ к UserImage ui ui.UserID=u.ID;
ВСТАВИТЬ В Настройки (Name, UserID, State) ЦЕННОСТИ («Домашние животные», 13, 1);

9. Выберите и заблокируйте несколько таблиц для 1 записи и вставьте в одну из них перед снятием блокировки. например:

НАЧАТЬ СДЕЛКУ;
ВЫБРАТЬ *
ОТ пользователя u
ПРИСОЕДИНЯЙТЕСЬ к предпочтениям p ON p.UserID=u.ID
ПРИСОЕДИНЯЙТЕСЬ к UserImage ui ui.UserID=u.ID
ГДЕ u.ID = 9001
ДЛЯ ОБНОВЛЕНИЯ;
ВСТАВИТЬ В Настройки (Name, UserID, State) ЦЕННОСТИ («Домашние животные», 13, 1);
СОВЕРШИТЬ;

Пример использования

Ожидается, что проект начнется со 107 записей без всплеска данных после его запуска. После этого ожидается, что темпы роста составят в среднем 220 000 записей в день в течение первого года.

Ниже представлена ​​запутанная версия полного API этого проекта и всех таблиц, которые использует каждый API. Они сгруппированы по операторам Select, Update и Insert. Число в процентах рядом с каждым API — это ожидаемая частота использования этого API.

1. API1 (используется всеми API) (24%)
   Вставлять: ТаблицаF
2. API2 (используется большинством API) (17%)
   Выбирать: ТаблицаG, ТаблицаH
   Обновлять: ТаблицаH
3. API3 (11%)
   Выбирать: ТаблицаL, ТаблицаM, ТаблицаJ, ТаблицаN, ТаблицаO, ТаблицаP, ТаблицаI, ТаблицаQ, ТаблицаR, ТаблицаE, ТаблицаS, ТаблицаT, ТаблицаU, ТаблицаV
   Вставлять: ТаблицаW
4. API4 (9%)
   Обновлять: ТаблицаA, ТаблицаB, ТаблицаC
   Вставлять: ТаблицаD
5. API5 (5%)
   Выбирать: ТаблицаE, ТаблицаI, ТаблицаK
6. API6 (4%)
   Вставлять: ТаблицаE
7. API7 (4%)
   Обновлять: Таблица G
   Вставлять: Таблица G
8. API8 (4%)
   Выбирать: ТаблицаL, ТаблицаM, ТаблицаJ, ТаблицаN, ТаблицаO, ТаблицаP, ТаблицаI, ТаблицаQ, ТаблицаR, ТаблицаE, ТаблицаS, ТаблицаT, ТаблицаU, ТаблицаV
9. API9 (4%)
   Выбирать: ТаблицаL, ТаблицаO, ТаблицаY
   Вставлять: ТаблицаO
10. API10 (4%)
    Выбирать: ТаблицаG, ТаблицаX, ТаблицаH
    Обновлять: ТаблицаG, ТаблицаX
    Вставлять: ТаблицаG, ТаблицаX, ТаблицаH
11. API11 (2%)
    Выбирать: Таблица I, Таблица J
12. API12 (2%)
    Выбирать: ТаблицаL, ТаблицаM, ТаблицаJ, ТаблицаN, ТаблицаO, ТаблицаP, ТаблицаI, ТаблицаQ, ТаблицаR, ТаблицаE, ТаблицаS, ТаблицаT, ТаблицаU, ТаблицаV, ТаблицаK
13. API13 (2%)
    Вставлять: ТаблицаM
14. API14 (2%)
    Выбирать: ТаблицаL, ТаблицаO, ТаблицаY, ТаблицаQ, ТаблицаR, ТаблицаE
    Вставлять: ТаблицаL
15. API15 (2%)
    Обновлять: Таблица G
16. API16 (2%)
    Обновлять: ТаблицаX
17. API7 (1%)
    Выбирать: ТаблицаQ, ТаблицаJ, ТаблицаI, ТаблицаX
18. API18 (1%)
    Выбирать: ТаблицаJ
    Обновлять: ТаблицаJ, ТаблицаG
    Вставлять: ТаблицаJ
19. API19 (0%)
    Обновлять: Таблица G
20. API20 (0%)
    Обновлять: Таблица G

Анализ

Количество записей в этой БД 107 с увеличением на 220 000 в день за первый год:
10 000 000 + (365 х 220 000) = 90 300 000 = ~10^8 записей через 1 год

Ожидаемые частоты API для этого проекта дают 135 операций записи на каждые 333 чтения.

Следующие таблицы являются теми, в которые будет производиться запись. Число представляет собой процент запросов API:
ТаблицаF: 24%
ТаблицаH: 21%
Таблица G: 19%
ТаблицаW: 11%
ТаблицаX: 10%
Таблица А: 9%
Таблица Б: 9%
Таблица C: 9%
Таблица D: 9%
Таблица E: 4%
Таблица O: 4%
ТаблицаJ: 2%
ТаблицаL: 2%
Таблица М: 2%

Следующие таблицы будут считаны из:
Доски: 25%
Таблица E: 24%
ТаблицаL: 23%
Таблица G: 21%
ТаблицаH: 21%
ТаблицаJ: 20%
ТаблицаQ: 20%
ТаблицаR: 19%
Таблица М: 17%
Таблица N: 17%
Таблица P: 17%
Таблицы: 17%
Таблица Т: 17%
ТаблицаU: 17%
Таблица К: 7%
ТаблицаY: 6%
ТаблицаX: 5%

Рекомендации

Это число значительно ниже 109 записей, и поэтому это БД большого размера. Ожидается, что темпы роста не превысят того уровня, на который могут оперировать SQL DB с memcache и NoSQL DB в течение первого года. Поэтому рекомендуется использовать базу данных SQL с memcache и Couchbase.

Мы должны установить специальную обработку для двух верхних таблиц, в которые чаще всего записываются, так как все, что превышает 20%, должно быть отделено от любых читаемых таблиц, когда это возможно.

Об авторе

Абдалла Чамас — архитектор программного обеспечения с 11-летним опытом работы на момент написания этой статьи в апреле 2017 года. Он является скрам-мастером и бэкэнд-разработчиком, использующим Java, PHP, MySQL, Microsoft SQL Server и Oracle. Он был основным разработчиком ApstrataDB и нескольких технологических стартапов, ориентированных на пользователей.