Карта решений — первая ставка
Чему научишься
- прикидывать подходящий вид хранилища для задачи магазина ещё до подробного знакомства с каждым;
- не отправлять данные в документное хранилище только из-за разной формы записей;
- записать свою ставку и в конце курса проверить, где она совпала с разбором.
Комендант кладёт перед тобой опись — восемь задач, которые «Котомаркет» решал каждый день. «Где что лежало? Хотя бы прикинь. Подробности потом».
КВЕРИ: Здесь можно ошибаться. Записывай первую версию, а проверим её только в конце курса. Посмотрим, сколько решений удастся угадать до знакомства с самими хранилищами.
Восемь карточек
Нажми «Выполнить»: show_cards() — учебная функция этого урока, она печатает восемь задач «Котомаркета» и шесть вариантов, где их хранить.
Не пытайся угадать хранилище по одному слову в карточке. «Сессии», «платежи» или «поиск» сами по себе ответа не дают. Сначала посмотри, что программа делает с этими данными.
Начни с обращения к записи. Программа знает точный ключ и хочет быстро получить связанную с ним запись? Или ей нужно найти записи по условию, словам либо связям между объектами? Это разные задачи, даже если объём данных одинаковый.
Потом посмотри на ритм работы. Одни сведения программа читает снова и снова, другие постоянно меняет. Иногда можно ненадолго увидеть старый ответ, а иногда после изменения нужен самый свежий.
Последний вопрос неприятный, зато полезный: что случится, если часть сведений исчезнет? Потерянный готовый список можно собрать заново. С заказами и платежами такая беспечность уже опасна.
В карточках сказано не всё. Где информации не хватает, делай разумное предположение и записывай ставку. Это черновое решение, а не экзамен.
Как делать ставку
Перед тобой сразу восемь задач и шесть вариантов. Если держать все признаки в голове одновременно, выбор быстро превращается в угадайку. Поэтому прогоняй каждую карточку через одинаковые вопросы.
Сначала выясни, как программа добирается до нужных сведений. Когда известен точный ключ, задача устроена иначе, чем поиск по словам, условию или связям между объектами.
Затем сравни чтение и изменения. Готовый результат, который показывают часто, ведёт себя иначе, чем сведения, которые постоянно переписывают.
После этого спроси про свежесть. Если одна копия немного отстаёт, пользователь вообще это заметит? Для одной задачи старый ответ на короткое время терпим, для другой он меняет смысл действия.
Наконец, оцени цену потери. Некоторые сведения можно получить заново из основной базы или заново посчитать. Другие исчезнуть не должны.
Только после этих вопросов смотри на размер и форму записей. Так слово «документы», «граф» или «поиск» не подменит саму задачу.
Самая частая ловушка
В описи есть строка «карточки 20 товаров с разными характеристиками». Легко увидеть слова «разные характеристики» и сразу выбрать документы: у одной карточки есть одни поля, у другой — другие.
Разная форма записи действительно может сделать документы удобными. Но она отвечает только на вопрос о том, как уложить сведения внутри записи. Она ничего не говорит о том, как программу будут просить эти сведения находить, как часто их менять и насколько свежим нужен ответ.
Допустим, карточку обычно находят по номеру товара, а меняют раз в неделю. Ради одной только разницы в полях отдельное документное хранилище может вообще не понадобиться. Основная база тоже справится: PostgreSQL умеет хранить прямо в столбце таблицы, и у каждого товара внутри будет свой набор полей.
Есть ещё один полезный вопрос: что программе обычно нужно после открытия карточки? Если она получает сразу название, цену и особые характеристики товара, такую карточку удобно читать целиком одним обращением. По смыслу это похоже на папку с анкетой товара: открыл папку и сразу видишь всё, что относится к этой карточке, вместо того чтобы собирать её по частям.
Но и этот признак не выбирает хранилище в одиночку. Карточку могут удобно читать целиком, а искать товары при этом по словам покупателя. Тогда у этих двух действий разные требования, и ставку нужно делать по конкретной задаче из описи.
В реальной работе такой выбор возникает рядом с PostgreSQL, MongoDB, Redis, Elasticsearch и Neo4j. Обычно его обсуждают ещё до настройки самих систем: сначала перечисляют обращения программы к данным, а уже потом решают, какое хранилище за что отвечает.
КВЕРИ: На «разные поля — значит, документы» спотыкаются постоянно. Потом оказывается, что новое хранилище почти ничего не дало, зато его теперь нужно обновлять, наблюдать за ним и чинить по ночам.
None на один из вариантов — «основная база», «ключ-значение», «документы», «много серверов», «поиск» или «граф». Названия задач слева не трогай. «Топ товаров дня» — это готовый список самых просматриваемых товаров, который часто показывают на главной странице. Засчитывается любая заполненная ставка: проверка напечатает её — скопируй себе в заметки, в последней главе сравним.Главное из урока
- База данных хранит сведения программы; таблица — самый частый, но не единственный способ.
- Хранилище выбирают по тому, как программа работает с данными: по чему ищет, как часто обращается, насколько свежим нужен ответ и что нельзя потерять.
- Копии на других узлах помогают пережить поломку, но одна копия может отставать от другой. Если связь между ними оборвётся, придётся решать, что нужнее прямо сейчас: самый свежий ответ или возможность продолжать работу.
- Ставка составлена. Сохрани её в заметках — в последней главе сравним её с разбором.
Пока ты составляешь опись, на панели кэша гаснет ещё один огонёк — в кэше «Котомаркета» вышел чей-то срок жизни. КВЕРИ смотрит на часы: «Если собираешься читать кэш — сейчас самое время».