Примечания к выпуску

D1 позволяет настраивать юрисдикции для локализации данных

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

D1 автоматически повторяет запросы только для чтения

Теперь D1 распознаёт запросы только для чтения и при ошибках, которые можно устранить повтором, автоматически пытается выполнить их заново до двух раз. Количество попыток выполнения доступно в возвращаемом метаданные ответа свойство total_attempts.

На данный момент повторно выполняются только запросы на чтение, то есть запросы, содержащие исключительно следующие ключевые слова SQLite: SELECT, EXPLAIN, WITH. Запросы, содержащие любые ключевое слово SQLite, в результате которых происходит запись в базу данных, не повторяются.

Доля успешных повторов среди ошибок только для чтения, допускающих повтор, варьируется от 5% до 95% в зависимости от типа и длительности ошибки (например, сетевых или других внутренних ошибок).

Доля успешных повторов среди всех ошибок, допускающих повтор, ниже, что говорит о наличии запросов на запись, которые можно повторить. Поэтому мы рекомендуем пользователям D1 продолжать применять повторные попытки в своём собственном коде для запросов, которые не являются только для чтения, но идемпотентны согласно бизнес логике приложения.

D1 гарантирует, что ни одна попытка повтора не приведёт к записи в базу данных, поэтому автоматические повторы безопасны от побочных эффектов, даже если через определение запросов только для чтения проскользнёт запрос, вносящий изменения. Для этого D1 проверяет наличие изменений после каждого выполнения запроса, и если попытка повтора всё же привела к записи, запрос откатывается.

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

Максимальный объём хранилища D1 на один аккаунт для платного плана Workers теперь составляет 1 ТБ

Максимальный объём хранилища D1 на аккаунт для пользователей на тарифе Workers Paid увеличен с 250 ГБ до 1 ТБ.

Доступ к резервным копиям баз данных D1 alpha удален

После прекращения доступа к запросам для баз данных D1 alpha, начиная с 2024-08-23, резервные копии баз данных D1 alpha больше нельзя создавать или получать к ним доступ с помощью wrangler d1 backup, доступно начиная с wrangler v3.

Если вы хотите сохранить резервную копию базы данных D1 alpha, используйте wrangler d1 backup до 2025-07-01. Резервную копию альфа-версии D1 можно использовать, чтобы перенести к недавно созданной базе данных D1 в общедоступном состоянии (GA).

50-500ms Faster D1 REST API Requests

Пользователям, использующим Cloudflare REST API для запросов к своей базе данных D1 теперь видят более низкую сквозную задержку запросов, поскольку аутентификация D1 выполняется в ближайшем дата-центре сети Cloudflare, принявшем запрос. Ранее для аутентификации требовалось проксировать запросы D1 REST API в основные централизованные дата-центры Cloudflare, что добавляло сетевые обращения туда и обратно и увеличивало задержку.

Улучшение задержки составляет от 50 до 500 мс в зависимости от местоположения запроса и расположение базы данных и применяется только к REST API. Запросы REST API и базы данных за пределами США получают больше преимуществ, поскольку основные ключевые дата-центры Cloudflare расположены в США.

конечные точки запросов D1, такие как /query и /raw демонстрируют наиболее заметные улучшения, поскольку больше не обращаются к основным дата центрам Cloudflare. Конечные точки уровня управления D1, например для создания и удаления баз данных, получают менее значительные улучшения, поскольку им по прежнему требуется доступ к основным дата центрам Cloudflare для остальных метаданных уровня управления.

Исправление ошибки с правами доступа D1 HTTP API

Ошибка в разрешениях, которая позволяла аккаунту Cloudflare и пользователю API-токены с D1:Read разрешение и Edit разрешение на другой продукт Cloudflare для выполнения записи в базу данных D1 является фиксированным. D1:Edit разрешение требуется для любой записи в базу данных через HTTP API.

Если вы использовали существующий API-токен без D1:Edit разрешение для внесения изменений в базу данных D1 через HTTP API, вам нужно будет создать или изменить API-токены чтобы явно включить D1:Edit разрешение.

D1 Read Replication Public Beta

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

Workers может использовать доступные только для чтения копии базы данных, называемые репликами для чтения, с помощью D1 Sessions API. Сессия объединяет все запросы одной логической сессии вашего приложения. Например, сессия может соответствовать всем запросам, поступающим из определённой сессии браузера. При использовании Sessions API запросы D1 в рамках сессии гарантированно последовательно согласованный чтобы избежать проблем с согласованностью данных. D1 bookmarks можно использовать из предыдущего сеанса для обеспечения логической согласованности между сеансами.

// retrieve bookmark from previous session stored in HTTP header
const bookmark = request.headers.get("x-d1-bookmark") ?? "first-unconstrained";

const session = env.DB.withSession(bookmark);
const result = await session
  .prepare(`SELECT * FROM Customers WHERE CompanyName = 'Bs Beverages'`)
  .run();
// store bookmark for a future session
response.headers.set("x-d1-bookmark", session.getBookmark() ?? "");

Реплики для чтения автоматически создаются Cloudflare (в настоящее время по одной в каждом поддерживаемом регион D1) активны или неактивны в зависимости от трафика запросов и прозрачно маршрутизируются Cloudflare без дополнительной платы.

Чтобы опробовать репликацию чтения D1, разверните следующий код Worker с использованием Sessions API. Он предложит вам создать базу данных D1 и включить для неё репликацию чтения.

Подробнее о реализации репликации для чтения см. в нашем запись в блоге.

D1 поддерживает `PRAGMA optimize`

Теперь D1 поддерживает PRAGMA optimize команду, которая может повысить производительность запросов к базе данных. Рекомендуется выполнять эту команду после изменения схемы (например, после создания индекса). Подробнее см. в PRAGMA optimize, где это описано подробнее.

Исправлена ошибка при доступе только для чтения к D1 через интерфейс и REST API /query.

Исправлена ошибка в разрешениях D1, из-за которой пользователи с ролями только для чтения в интерфейсе и пользователи с API-токенами только для чтения через /query REST API чтобы выполнять запросы, изменяющие базы данных. Действия в интерфейсе через Tables вкладке, например создание и удаление таблиц, ошибочно разрешались при доступе только для чтения. Однако действия в интерфейсе через Console вкладке эта ошибка не затрагивала и корректно требовала доступа на запись.

Запросы на запись с доступом только для чтения теперь будут завершаться ошибкой. Если вы полагались на прежнее некорректное поведение, назначьте пользователям правильные роли или выдайте API-токенам разрешения на выполнение запросов на запись D1.

D1 начнёт применять лимиты бесплатного тарифа с 10 февраля 2025 года.

D1 начнёт применять ежедневный лимиты бесплатного тарифа с 2025-02-10. Эти ограничения касаются только аккаунтов на плане Workers Free.

С 2025-02-10, если вы не предпримете никаких действий и превысите дневные лимиты бесплатного тарифа, запросы к базам данных D1 через Workers API и/или REST API будут возвращать ошибки, пока лимиты не сбросятся в 00:00 UTC.

Чтобы обеспечить бесперебойную работу сервиса, перейдите на план Workers Paid из страница планов. Минимальная ежемесячная сумма оплаты составляет $5. См. план Workers Paid и лимиты D1.

Чтобы лучше понимать текущее использование, см. биллинговые метрики для прочитанных и записанных строк, которые можно найти на панель управления D1 или GraphQL API.

Задержка запросов D1 Worker API снижается на 40-60%.

D1 снизил сквозную задержку запросов Worker API на 40-60%, устранив избыточные сетевые обращения для каждого запроса.

Задержка запросов p50, p90 и p95, агрегированная по всему сервису D1. Эти значения задержки являются ориентировочными и не отражают точное улучшение вашей рабочей нагрузки.

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

Устранение избыточных сетевых обращений также применяется к REST API. Однако REST API по-прежнему зависит от централизованных дата-центров Cloudflare для аутентификации, что снижает относительный прирост производительности.

Базы данных D1 alpha больше не принимают SQL-запросы

После предупреждение об устаревании начиная с 2024-04-30 базы данных D1 alpha перестали принимать запросы (по-прежнему можно создавать резервные копии и получать их).

Запросы к базам данных D1 alpha теперь возвращают ошибку HTTP 400 со следующим текстом:

You can no longer query a D1 alpha database. Please follow https://developers.cloudflare.com/d1/platform/alpha-migration/ to migrate your alpha database and resume querying.

Перейти на новую, общедоступную версию D1 можно, выполнив руководство по миграции базы данных alpha.

Исправлена ошибка в типах TypeScript для API-метода run()

run() метод в рамках D1 Client API имел неверное (устаревшее) определение типа, которое было исправлено начиная с @cloudflare/workers-types версия 4.20240725.0.

Правильное определение типа: stmt.run<T>(): D1Result, как run() возвращает результирующие строки запроса. Ранее неверно определение типа было stmt.run(): D1Response, которое возвращает только метаданные запроса и не возвращает результатов.

HTTP API теперь возвращает ошибку HTTP 429 для перегруженных баз данных D1

Ранее в D1 HTTP API возвращал HTTP 500 Internal Server ошибку для запросов, поступивших в момент перегрузки базы данных D1. Такие запросы теперь корректно возвращают HTTP 429 Too Many Requests ошибка.

D1 API Workers не затрагивается этим изменением.

Базы данных D1 alpha перестанут принимать SQL-запросы в реальном времени 15 августа 2024 года

Ранее устаревшая alpha баз данных D1 необходимо перенести до 15 августа 2024 года, чтобы они продолжали принимать новые запросы.

См. руководство по миграции базы данных alpha чтобы перейти на новую, общедоступную архитектуру базы данных.

HTTP API теперь возвращает ошибку HTTP 400 для недопустимых запросов

Ранее в D1 HTTP API возвращал HTTP 500 Internal Server ошибку для недопустимого запроса. Некорректный SQL-запрос теперь корректно возвращает HTTP 400 Bad Request ошибка.

D1 API Workers не затрагивается этим изменением.

Базы данных D1 alpha устарели

Теперь, когда D1 стал общедоступным (GA) и готовым к продакшену, базы данных D1 alpha считаются устаревшими: их следует перенести для повышения производительности и надёжности, а также для дальнейшей поддержки.

См. руководство по миграции базы данных alpha чтобы перейти на новую, общедоступную архитектуру базы данных.

D1 общедоступен

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

• Разработчики на плане Workers Paid теперь имеют лимит 10 ГБ на базу данных (ранее 2GB), который можно совмещать с существующим лимитом 50,000 баз данных на аккаунт.
• Разработчики на плане Workers Free сохраняют лимит 500 МБ на базу данных и могут создавать до 10 баз данных на аккаунт.
• Базы данных D1 можно экспортирован как файл SQL.

Изменение поведения `wrangler d1 execute` по умолчанию

По состоянию на [email protected], wrangler d1 execute и wrangler d1 migrations apply теперь по умолчанию используют локальную базу данных, чтобы соответствовать поведению по умолчанию у wrangler dev.

Теперь также можно указать один из --local или --remote чтобы явно указать wrangler, в каком окружении следует выполнять команды.

Тарификация использования D1

С 2024-03-05 использование D1 начнёт учитываться и может привести к списаниям в будущем расчётном периоде аккаунта.

Разработчики на плане Workers Paid, чьё использование D1 превышает включённые лимиты повлечёт расходы согласно тарификация D1.

Разработчики на плане Workers Free могут пользоваться включёнными в план лимитами. Для использования сверх указанных ниже лимитов потребуется оформить платный план Workers Paid за $5/month.

Тарифицируемые метрики аккаунта доступны в Cloudflare Dashboard и GraphQL API.

Изменения API для `run()`

Более раннее изменение (внесённое 2024-02-13) в run() метод инструкции запроса была отменена.

run() теперь возвращает D1Result, включая строки результата, что соответствует исходному поведению до изменения от 2024-02-13.

Будущее изменение run() чтобы вернуть D1ExecResult, как и было изначально задумано и задокументировано, будет доступно только через дата совместимости чтобы не нарушить работу существующих Workers, которые полагаются на то, как run() в настоящее время работает.

Изменения API для `raw()`, `all()` и `run()`

D1 raw(), all() и run() методы инструкции запроса были обновлены, чтобы отражать ожидаемое поведение и улучшить совместимость с библиотеками ORM.

raw() теперь корректно возвращает результаты в виде массива массивов, что позволяет правильно обрабатывать повторяющиеся имена столбцов (например, при объединении таблиц), в отличие от all(), которое не изменилось и возвращает массив объектов. Чтобы включить массив имён столбцов в результаты при использовании raw(), используйте raw({columnNames: true}).

run() больше не возвращает по ошибке D1Result и вместо этого возвращает D1ExecResult как изначально задумано и задокументировано.

Это может стать критическим изменением для некоторых приложений, которые ожидали raw() чтобы вернуть массив объектов.

См. клиентский API D1 чтобы подробно ознакомиться с методами запросов D1, типами возвращаемых значений и поддержкой TypeScript.

Поддержка LIMIT в операторах UPDATE и DELETE

Теперь D1 поддерживает добавление LIMIT предложение к UPDATE и DELETE операторов, что позволяет ограничить последствия потенциально опасной операции.

Автоматическое резервное копирование для устаревших баз данных alpha отключено

Базы данных, использующие устаревший alpha-бэкенд D1, больше не будут запускать автоматизированные ежечасные резервные копии. Вы по-прежнему можете создавать ручные резервные копии этих баз данных.

Команда D1 рекомендует перейти на новый продакшен-бэкенд, для чего потребуется экспортировать и импортировать имеющиеся данные. Продакшен-бэкенд D1 работает быстрее исходного alpha-бэкенда. Новый бэкенд также поддерживает Time Travel, что позволяет восстановить базу данных на любую минуту за последние 30 дней без необходимости в почасовых или ручных снимках.

Создавайте до 50,000 баз данных D1

Разработчики, использующие D1 на плане Workers Paid, теперь могут создавать до 50,000 баз данных в рамках постоянного увеличения лимитов D1.

• Это также позволяет реализовать сценарии с отдельной базой данных на каждого пользователя и изолировать данные разных клиентов.
• Общий объём хранилища на аккаунт теперь составляет 50 ГБ.
• D1 аналитика и метрики предоставляют данные об использовании в разрезе каждой базы данных.

Если вам нужно создать более 50,000 баз данных или увеличить объем хранилища на аккаунт, свяжитесь с нами команде D1, чтобы обсудить это.

Публичная бета D1 уже доступна

D1 теперь доступен в публичной бета-версии, а лимиты хранилища увеличены:

• Разработчики на плане Workers Paid теперь имеют лимит 2 ГБ на базу данных (ранее 500 МБ) и могут создавать 25 баз данных на аккаунт (ранее 10). Во время публичной беты эти лимиты будут и далее увеличиваться автоматически.
• Разработчики на плане Workers Free сохраняют лимит 500 МБ на базу данных и могут создавать до 10 баз данных на аккаунт.

Базы данных должны использовать D1 новая подсистема хранения чтобы воспользоваться увеличенными лимитами базы данных.

Прочитайте блог анонсов с подробностями о новых возможностях в бета версии и о том, что ожидает D1 в будущем.

Количество строк теперь возвращается для каждого запроса

Теперь D1 возвращает количество rows_written и rows_read для каждого выполненного запроса, что позволяет оценить стоимость запроса как для цены и оптимизация индексов целей.

meta объект, возвращаемый в Клиентский API D1 содержит общее количество прочитанных строк (rows_read) и записанных строк (rows_written) этим запросом. Например, запрос, который выполняет полное сканирование таблицы (например, SELECT * FROM users) из таблицы с 5000 строками вернёт rows_read значение 5000:

"meta": {
  "duration": 0.20472300052642825,
  "size_after": 45137920,
  "rows_read": 5000,
  "rows_written": 0
}

См. документация по тарификации D1 чтобы понять, как измеряются операции чтения и записи. Использование D1 остаётся бесплатным в течение alpha-периода.

Привязка D1 через панель управления Cloudflare

Теперь вы можете привязать базу данных D1 к вашим Workers прямо в Панель управления Cloudflare. Чтобы привязать D1 из панели управления Cloudflare, выберите свой проект Worker -> Настройки -> Переменные -> и выберите D1 Database Bindings.

Примечание: если вы ранее развернули Worker с привязкой базы данных D1 с версией wrangler до 3.5.0, вам нужно обновиться до wrangler v3.5.0 прежде чем сможете редактировать привязки базы данных D1 в Cloudflare dashboard. На новые проекты Workers это ограничение не распространяется.

Пользователи устаревших баз данных D1 alpha, которые ранее вручную добавляли к привязке базы данных префикс __D1_BETA__ следует удалить это в рамках данного обновления. Ваши скрипты Worker должны обращаться к базе данных D1 через env.BINDING_NAME только. См. последнюю вводное руководство по D1 с лучшими практиками.

Всем пользователям alpha-версии D1 рекомендуем перейти на wrangler 3.5.0 (или более новой), чтобы использовать улучшенные типы TypeScript и будущие обновления D1 API.

Лимит на одну базу данных теперь составляет 500 МБ

Базы данных, использующие D1 новая подсистема хранения теперь могут увеличиваться до 500 MB каждая, по сравнению с прежним ограничением в 100 MB. Это касается как существующих, так и новых баз данных.

См. Лимиты чтобы узнать об ограничениях D1.

Новая подсистема хранения по умолчанию

Базы данных, созданные через панель управления Cloudflare и Wrangler (начиная с v3.4.0) теперь по умолчанию используют новую подсистему хранения D1. Новый бэкенд может быть в 6-20 раз быстрее чем исходный alpha-бэкенд D1.

Чтобы узнать, какую подсистему хранения использует ваша база данных, выполните wrangler d1 info YOUR_DATABASE и проверьте поле version в выводе.

Базы данных с version: beta используют новый бэкенд хранения и поддерживают Time Travel API. Базы данных с version: alpha используют только старый, устаревший бэкенд D1.

Time Travel

Time Travel теперь доступен. Time Travel позволяет восстановить базу данных D1 на любую минуту за последние 30 дней (тариф Workers Paid) или 7 дней (тариф Workers Free) без дополнительной платы за хранение или восстановление.

См. Time Travel документацию и узнайте, как перемещаться назад во времени.

Базы данных, использующие D1 новая подсистема хранения могут использовать Time Travel. Time Travel заменяет резервное копирование на основе снимков используется для устаревших баз данных alpha.

Метрики и аналитика

Теперь можно просмотреть метрики в разрезе каждой базы данных одновременно через Панель управления Cloudflare и GraphQL Analytics API.

D1 в настоящее время предоставляет количество операций чтения и записи в секунду, размер ответа на запрос и процентили задержки запросов.

Документация по генерируемым столбцам

Опубликована новая документация о том, как использовать поддержку D1 для генерируемые столбцы чтобы определить столбцы, которые динамически генерируются при записи (или чтении). Генерируемые столбцы позволяют извлекать данные из Объекты JSON или использовать результат работы других SQL-функций.

Прекращение поддержки Error.cause

По состоянию на wrangler v3.1.1 клиентский API D1 теперь возвращает подробные сообщения об ошибках внутри верхнеуровневого Error.message свойство и больше не требует от разработчиков проверять Error.cause.message свойство.

Чтобы упростить переход с предыдущей Error.cause поведение, подробные сообщения об ошибках по-прежнему будут указываться в Error.cause а также верхний уровень Error объект примерно до 14 июля 2023 года. Будущие версии обоих wrangler и клиентский API D1 больше не будет заполнять Error.cause после этой даты.

Новый экспериментальный бэкенд

У D1 появился новый экспериментальный бэкенд хранения, который значительно улучшает пропускную способность запросов, задержку и надёжность. В ближайшем будущем этот экспериментальный бэкенд станет бэкендом по умолчанию. Чтобы создать базу данных с использованием экспериментального бэкенда, используйте wrangler и задайте --experimental-backend флаг при создании базы данных:

$ wrangler d1 create your-database --experimental-backend

Подробнее об экспериментальном бэкенде см. в блог анонсов.

Подсказки о местоположении

Теперь можно указать подсказка о расположении при создании базы данных D1, что повлияет на расположение ведущего узла (записывающего). По умолчанию D1 автоматически создаёт вашу базу данных в регионе, близком к тому месту, откуда был отправлен запрос на её создание. В большинстве случаев это позволяет D1 самостоятельно выбрать оптимальное расположение для вашей базы данных.

Запрос JSON

Новая документация была опубликована и подробно описывает обширную поддержку функций JSON в D1. Функции JSON позволяют разбирать, запрашивать и изменять JSON прямо в SQL запросах, сокращая количество обращений к базе данных или объём запрашиваемых данных.