app engine_Google App Engine：数据库策略

app engine

Traditional enterprize systems have well developed designs & strategies around relational databases. Relational database products are well developed not only from a data consistency point of view (ACID) but also from a database administration perspective. Databases are maintained in house or sourced to a competent vendor who has a well developed process for backup, migration and security.

传统的企业系统围绕关系数据库具有完善的设计和策略。 关系数据库产品不仅从数据一致性角度(ACID)，而且从数据库管理角度来看，都得到了很好的开发。 数据库可以在内部维护，也可以提供给合格的供应商，该供应商拥有完善的备份，迁移和安全流程。

In contrast to this, the emerging cloud technologies employ NO SQL database structure more often than not. The database is maintained in the cloud provider’s infrastructure. Database administration, especially backup procedures, are loosely defined & have not matured so far and are evolving over time. If a business is moving from a traditional relational DB to cloud based DB, the move can be quite overwhelming when taking into account all of these factors.

与此相反，新兴的云技术经常采用NO SQL数据库结构。 数据库维护在云提供商的基础架构中。 数据库管理(尤其是备份过程)的定义很松散，到目前为止还不成熟，并且随着时间的推移而发展。 如果企业正在从传统的关系数据库迁移到基于云的数据库，那么考虑到所有这些因素，这种迁移可能会非常困难。

Knowing the right tools and knowledge of risks makes database strategy for cloud worth the benefits of clouds. Lets go through what are our options with GAE today. We wont go through development level details in this article, but am to understand the scenario at a high level.

了解正确的工具和风险知识使云数据库策略值得云的好处。 让我们来了解一下今天使用GAE的选择。 我们不会在本文中介绍开发级别的详细信息，而是希望从更高层次上了解这种情况。

实施策略：SQL＆不使用SQL！ (Implementation Strategy: SQL & NO SQL!)

If you are planing to move your existing application to GAE, and you have JPA/JDO layers in your application, the task is fairly easy. JPA/JDO interfaces let you store object data into database without having database specific code. It works with a different kind of database, thus making it easy to port your application to a different kind of storage. This strategy is good even for new application development, specially if you want to keep the option of moving back to a traditional model/database at a later point. There are certainly some limitations or “unsupported features” with GAE like “many to many relationships” or “joins in queries”, and you will have to account for model change if it’s a case of migration from existing app.

如果您打算将现有应用程序迁移到GAE，并且您的应用程序中包含JPA / JDO层，则该任务相当容易。 JPA / JDO接口使您可以将对象数据存储到数据库中，而无需数据库特定的代码。 它可以与其他类型的数据库一起使用，因此可以轻松地将您的应用程序移植到其他类型的存储中。 即使对于新的应用程序开发，此策略也很好，特别是如果您希望以后再选择转回传统模型/数据库时，这种策略尤其有用。 GAE当然存在一些限制或“不受支持的功能”，例如“多对多关系”或“查询联接”，如果是从现有应用程序迁移的情况，则必须考虑模型更改。

For a complete NO-SQL approach, you have more options. While you can use Google data-store directly with GAE provided APIs, you will have certain things to deal with which might mean extra work, for example, Google datastore deals with entities while your application might be using POJOs. Also, transaction management with the GAE datastore API is slightly complicated. You will also have to deal with untyped keys etc. But to our rescue, there are few frameworks which can help us like Objectify, twig and slim

对于完整的NO-SQL方法，您有更多选择。 虽然您可以直接通过GAE提供的API使用Google数据存储，但是您需要处理某些事情，这可能意味着额外的工作，例如，当您的应用程序可能使用POJO时，Google数据存储处理实体。 此外，使用GAE数据存储区API进行的事务管理也有些复杂。 您还必须处理无类型的密钥等。但是，为了拯救我们，很少有框架可以像Objectify，twig和slim这样帮助我们。

Though Google has announced a SQL version of database to work with Google app engine, its still a “Labs” feature. In case you decide to go SQL, you would have simpler decision based on existing enterprise models. You would fit in an ORM framework using JDO/JPA or similar frameworks between database and application.

尽管Google宣布了SQL版本的数据库可与Google App Engine一起使用，但它仍然是“实验室”功能。 如果决定使用SQL，则基于现有企业模型的决策会更简单。 您将适合使用JDO / JPA的ORM框架或数据库与应用程序之间的类似框架。

迁移与备份 (Migration & Backup)

Migration frameworks for Google App Engine have not reached a desired level of maturity so far. One possibility is of course having custom programs which can run as “Task queue” and export data on a periodic basis to file which you can import in your DB. There are frameworks like AppRocket which offer DB backup in Python based applications and AppScale which implement, among others, GAE APIs and run as a virtual machine to offer various tasks.

到目前为止，Google App Engine的迁移框架尚未达到理想的成熟度。 一种可能性当然是拥有可作为“任务队列”运行的自定义程序，并定期将数据导出到文件中，然后将其导入数据库中。 像AppRocket这样的框架可以在基于Python的应用程序中提供数据库备份，而AppScale可以实现GAE API并作为虚拟机运行以提供各种任务。

But all above approaches sound unreliable once the size of database grows really big! And that’s a gap area which needs some work.

但是，一旦数据库规模变大，上述所有方法听起来都不可靠！ 这是一个空白，需要做一些工作。

可用性，一致性 (Availability, Consistency)

App engine offers it’s storage in two variants based on guarantee of availability and consistency. The high replication store provides higher read and write availability at the cost of higher latency writes and higher cost. Data is replicated across multiple data centres, but eventually most queries are consistent.

App Engine根据可用性和一致性的保证提供两种存储方式。 高复制存储以更高的延迟写入和更高的成本为代价提供更高的读写可用性。 数据跨多个数据中心复制，但是最终大多数查询是一致的。

The master slave datastore option uses one master and one slave datastore. The data is replicated asynchronously and hence consistency is guaranteed. But since only one datastore is used, availability might be “read only” during issues in datastore or planned downtimes. In this case, you also need to design the application to be able to support “read-only-no-write” to datastore.

主从数据存储选项使用一个主数据和一个从数据存储。 数据是异步复制的，因此可以保证一致性。 但是，由于仅使用一个数据存储，因此在数据存储出现问题或计划内停机期间，可用性可能是“只读”的。 在这种情况下，您还需要设计应用程序以支持对数据存储的“只读-不写”。

硬道理：表演 (The Last Word: Performance)

No topic on database is complete without talking about performance! Though a detailed treatment on performance would need a separate discussion. GAE datastore is not a traditional Relational DB and needs differently designed applications, different indexing techniques and most importantly a good understanding of what kind of store you are opting for.

如果不谈论性能，关于数据库的任何话题都是不完整的！ 尽管对性能的详细处理将需要单独讨论。 GAE数据存储区不是传统的关系数据库，需要设计不同的应用程序，不同的索引编制技术，最重要的是要对选择哪种类型的存储区有很好的了解。

For example, all entities being updated in a single transaction in master-slave store should be of same entity group, while this is not needed for high replication datastore. The design of application needs to be well thought from a different datastore perspective to leverage the scale and infrastructure!

例如，在主从存储中的单个事务中更新的所有实体应属于同一实体组，而高复制数据存储则不需要此实体组。 需要从不同的数据存储角度考虑应用程序的设计，以利用规模和基础架构！

Itachi Uchiha images from Shutterstock

来自Shutterstock的Itachi Uchiha图片

翻译自: https://www.sitepoint.com/google-app-engine-database-strategies/

app engine