We will now turn our attention to
the Datastore Commit Process. This process describes
to consistency rules for storing data. Datastore
has two consistency models, Eventual Consistency and Strong
Consistency. Let's look at these in more
detail. In this use case diagram we have
three things. Your Application, the datastore API
that your application calls and the datastore backend,
which performs work that your application is not involved
in. When your application wants to store an entity,
it performs a put operation towards the datastore API.
The datastore backend then writes this entity to a
log. When the write is completed, control is turned
back to your application. At this point the Datastore
backend has promised to write the entity to Datastore.
Observe however that the entity has not been written yet.
It has only been written to a log.
The Datastore backend now goes through to work to
make everything consistent. It does this by using the
login information to update the entity storage and then
it updates all the indexes. So observe that
when control is returned to your application, datastore may
not have done all the work required for the
data to be updated. Is this good or bad?
Well it's good, because this means that you have
less latency in your application. But the question now
becomes, what happens if a query is issued that
would retrieve the data your application just requested to
put into data store? Well, with eventual consistency the
data store API will not wait for this to
happen. So it only considers matching data that already
exists. That is data, that was already in data store
prior to your put call. And then it
returns that result. That's why it's called eventual
consistency. Queries will be eventually consistent with put
operations performed to what's the data store API.
نحن بصدد توجيه اهتمامك إلى
عملية تثبيت مخزن البيانات. تصف هذه العملية
قواعد الاتساق بغرض تخزين البيانات. لمخزن البيانات
نموذجي اتساق، اتساق لاحق
واتساق مشدد. فلنتعرف على هذين النوعين
بمزيد من التفاصيل. في مخطط حالة الاستخدام
لدينا ثلاثة أشياء. التطبيق، وواجهة API لمخزن البيانات
التي يقوم التطبيق باستدعائها، والخادم الخلفي لمخزن البيانات
.الذي ينفذ العمل الذي لا يشترك فيه تطبيقك
،فعندما يريد التطبيق تخزين أي كيان
.سيجري عملية "وضع" باتجاه واجهة API لمخزن البيانات
وسيقوم الخادم الخلفي لمخزن البيانات بكتابة الكيان
في سجل. عند الانتهاء من الكتابة
،سيعود التحكم إلى التطبيق. في هذه المرحلة
.سيكون على الخادم الخلفي لمخزن البيانات كتابة الكيان في مخزن البيانات
.لاحظ أنه لم تتم كتابة الكيان حتى الآن
.لقد تمت كتابته في سجل فقط
سيبدأ الخادم الخلفي لمخزون البيانات الآن في العمل
للتأكد من أن كل شيء متسقًا. سيتمكن من هذا عن طريق استخدام
معلومات تسجيل الدخول لتحديث مخزن الكيانات، ثم
تحديث كل الفهارس. لاحظ أنه
عندما يتم تحويل التحكم إلى التطبيق، فقد لا يكون
مخزن البيانات قد انتهى من جميع الأعمال اللازمة
لتحديث البيانات. هل هذا جيد أم سيء؟
حسنًا، يعد هذا جيدًا، لأنه يعني أن
،زمن الانتقال سيكون أقل في التطبيق. ولكن السؤال الآن هو
ماذا يحدث إذا أراد استعلام تم إصداره
استعادة البيانات التي قد طلب تطبيقك وضعها للتو
في مخزن البيانات؟ حسنًا، مع الاتساق اللاحق
لن تنتظر واجهة API لمخزن البيانات
حدوث هذا. فهي لا تعالج إلا بيانات مطابقة
موجودة بالفعل. تلك البيانات الموجودة بالفعل في مخزن البيانات
قبل إجراء الاستدعاء. ثم تقوم بإرجاع
تلك النتيجة. وهذا هو السبب وراء تسمية العملية
بالاتساق اللاحق. سيتم اتساق الاستعلامات لاحقًا
.مع عمليات الوضع التي تم تنفيذها في أي واجهة API لمخزن البيانات
Ahora pondremos atención
en el Proceso de Ejecución
del Almacén de Datos.
Este proceso describe
las normas de consistencia
para el almacenamiento de datos.
El almacén de datos tiene
dos modelos de consistencia.
Consistencia Eventual
y Consistencia Fuerte
Observémoslos con más detalle.
En este esquema de datos de uso,
tenemos tres cosas.
Tu aplicación,
el almacén de datos API
que tu aplicación requiere,
y la unidad de almacén de datos,
que realiza funciones
en las que tu aplicación
no está involucrada.
Cuando tu aplicación
quiere guardar una entidad
realiza un servicio permanente
hacia el almacén de datos API.
Luego la unidad del almacén
escribe esta entidad en un registro.
Cuando la escritura es completada,
el control regresa a tu aplicación.
Ahora la unidad del almacén de datos
ha prometido escribir esta entidad
al almacén de datos.
Pero observa que la entidad
aún no ha sido escrita.
Solo ha sido escrita en un registro.
Ahora la unidad del almacén de datos
repasa el trabajo
para hacerlo todo consistente.
Lo hace usando la información de registro
para actualizar el depósito de la entidad.
Y luego actualiza todos los índices.
Así que observa que cuando el control
regresa a tu aplicación,
el almacén de datos puede no haber hecho
el trabajo requerido
para actualizar los datos.
¿Esto es bueno o malo?
Es bueno,
significa que tienes
menos inactividad en tu aplicación.
Pero ahora la pregunta es,
¿qué pasa si la consulta es emitida
de manera que recupere los datos
que tu aplicación requirió poner
en el almacén de datos?
Con una consistencia progresiva,
el almacén de datos API
no esperará a que esto pase.
Solo tiene en cuenta unir los datos
ya existentes.
Estos son los datos,
que ya estaban en el almacén de datos
antes de tu compra/venta.
Y luego regresa ese resultado.
Por esto se llama
consistencia progresiva.
Las consultas serán
progresivamente consistentes
con las operaciones realizadas
al almacén de datos API.
もう一度Datastore Commit Processを
見てみましょう
このプロセスはデータ保存のルールの
一貫性を表しています
Datastoreには2つのモデルがあります
結果整合性と強い一貫性です
これらについてもっと詳しく見てみましょう
この使用事例ダイアグラムには
3つのことがあります
アプリケーション、
アプリケーションが呼び出すDatastore API、
アプリケーションが関わっていない作業をする
Datastoreバックエンドです
アプリケーションがエンティティを
保存しようとする時
Datastore APIに向かってput操作を行います
Datastoreバックエンドは
エンティティをログに書き込みます
書き込みが完了した時
コントロールはアプリケーションに返されます
この時点でDatastoreバックエンドは
エンティティをデータストアに書き込むことを
約束します
しかし書き込まれたわけではありません
ログに書き込まれただけです
Datastoreバックエンドは
すべてに一貫性を持たせる方向に働きます
エンティティ保存を更新するためのログイン情報を
使うことによってこれを行い
すべてのインデックスを更新します
したがってコントロールが
アプリケーションに返される時
データストアはデータ更新のために要求される
作業を完了していないかもしれません
これはよいことですか よくないことですか?
よいことですね アプリケーションの中の
待ち時間が少ないことを意味するからです
問題になるのは
アプリケーションがデータストアに入れるように
要求してきたデータを検索するクエリが出された時
どうなるかということです
結果整合性ではDatastore APIは
これが起きるのを待ってはいません
すでに存在しているデータを
マッチングすることを考慮するだけです
データはput呼び出しより以前に
データストアの中にあったものです
そしてそれは結果を返します
ゆえに結果整合性と呼ばれるのです
クエリは最終的にDatastore APIに
存在するものに対して行われた
put操作と結果整合性を保ちます
Voltemos agora nossa atenção para
o processo de confirmação do Datastore. Este processo descreve
as regras de consistência para o armazenamento de dados. O Datastore
tem dois modelos de consistência eventual e
forte. Vamos vê-las mais
detalhadamente. Neste diagrama de caso de uso temos
três elementos: o seu aplicativo, a API do Datastore
que o seu aplicativo chama e o back-end do Datastore,
que realiza o trabalho com o qual o aplicativo não está envolvido.
Quando o aplicativo quer armazenar uma entidade,
ele realiza uma operação PUT na API do Datastore.
O back-end do Datastore, então, escreve essa entidade em um
log. Quando esse processo é concluído, o controle é devolvido
ao aplicativo. Nesse momento, o back-end do
Datastore prometeu escrever a entidade no Datastore.
No entanto, observe que a entidade ainda não foi escrita.
Ela foi escrita apenas em um log.
O back-end do Datastore agora trabalha para
fazer com que tudo fique consistente. Ele faz isso usando as
informações de logon para atualizar o armazenamento da entidade e, em seguida,
atualiza todos os índices. Observe que
quando o controle é retornado ao aplicativo, talvez o Datastore
ainda não tenha realizado todo o trabalho necessário para
atualizar os dados. Isso é bom ou ruim?
É bom porque significa que há menos
latência no aplicativo. Mas a questão agora é:
o que acontece no caso de uma consulta que
retorna os dados que o aplicativo acabou de inserir
no Datastore? Com a consistência eventual,
a API do Datastore não esperará isso
acontecer. Ela considera fazer a correspondência somente com os dados que já
existem. Isto é, dados que já estavam no Datastore
antes da chamada PUT. E, depois, ela
retorna esse resultado. Daí o nome
consistência eventual. As consultas são eventualmente consistentes com as
operações PUT realizadas em direção à API do Datastore.
现在 我们将注意力转向
数据存储提交流程 此流程描述了
存储数据的一致性规则 数据存储
有两个一致性模块 最终一致性和
强一致性 我们来
详细看一看 在此用例图中
有三件事 你的应用、应用调用的数据存储 API
以及执行应用未参与的工作的
数据存储后端
当应用要存储实体时
它会对数据存储 API 执行 put 操作
随后 数据存储后端会将此实体写入
日志 完成写入之后 将控制
转回给应用 此时 数据存储后端
已承诺将实体写入数据存储
据观察 该实体尚未写入
只是将其写入了日志
数据存储后端现在努力
保持一致性 它使用登录信息
更新实体存储 然后更新所有索引
以保持一致性 所以
根据观察 当控制返回到应用时 数据存储尚未
完成更新数据
所需的所有工作 这是好事还是坏事呢?
这是好事 因为这意味着
你应用的延迟较低 但现在的问题是
如果查询检索只请求放入
数据存储中的应用数据
那么会出现什么情况?通过最终一致性
数据存储 API 不会
等待此情况出现 所以 它只考虑已存在的
匹配数据 也就是在你调用之前
已在数据存储中的数据 随后它会
返回结果 这就是它称为
最终一致性的原因 查询最终符合对
数据存储 API 执行的 put 操作