假设检验方差未知

by Rick Mak

麦瑞克(Rick Mak)

设计云数据库时如何处理未知数并做出假设 (How to handle unknowns and make assumptions when designing a cloud database)

Say you’re a developer who wants to build a note taking app. Let’s look at one feature detail with huge implications on your back-end. To write a note, your app will need to be able to save the data.

假设您是一名开发人员，想开发一个笔记应用程序。让我们来看一个对后端有重大影响的功能细节。要写笔记，您的应用将需要能够保存数据。

Saving a record to a database is straight forward. The key questions are:

将记录保存到数据库很简单。关键问题是：

Who will need to access that record?
谁需要访问该记录？
Will it only be your user, or will your user share it with others?
它只会是您的用户，还是会与他人共享？
Will your product be shoe-box app or a social app?
您的产品是鞋盒应用还是社交应用？

If you intend for the notes to be private to the author, you may conclude that you are making a shoe-box app. This means all data goes to a private DB (database).

如果您打算使注释对作者不公开，则可以得出结论，您正在制作鞋盒应用程序。这意味着所有数据都将进入私有DB(数据库)。

If you intend for your app to share notes with others, you may conclude it should be a public DB.

如果您打算让您的应用与他人共享笔记，则可以得出结论，它应该是公共数据库。

But will you know which it is before you start?

但是在开始之前您会知道是哪个吗？

And what will you do if you need to change your product as you go? Public DB and private DB isn’t the first thing most developers think about when they’re building an app. We encountered these question when we were building our back-end product for our developers, Skygear.

如果您需要随时随地更改产品，该怎么办？大多数开发人员在构建应用程序时都不会想到公共数据库和私有数据库。在为开发人员Skygear构建后端产品时，我们遇到了这些问题。

Because of our experience in building apps for clients, we assumed there was a right choice of database. And that our user would know how to choose.

基于我们在为客户构建应用程序方面的经验，我们认为数据库是正确的选择。而且我们的用户会知道如何选择。

How do you build a back-end for developers who aren’t sure of their products needs yet? Or for those who want to keep their options open in the future?

您如何为尚不确定其产品需求的开发人员构建后端？还是对于那些希望将来保留其选择权的人？

As the tech lead in the project, I’d like to share with you our decision making process from 2 years ago. I hope it helps future development teams approach unknowns and assumptions.

作为该项目的技术负责人，我想与您分享我们2年前的决策过程。我希望它可以帮助未来的开发团队应对未知和假设。

为什么我们开始考虑私有数据库与公共数据库？ (Why did we start thinking about private vs public DBs?)

Many apps require a back-end to store and query user data. The back-end is a lot of hard work to build and, let’s face it — not so enjoyable to create. Skygear is our open-source serverless back-end. It helps address common development features for mobile and web apps.

许多应用程序需要后端来存储和查询用户数据。后端是很多艰苦的工作，而让我们面对现实-创建起来并不那么愉快。 Skygear是我们的开源无服务器后端。它有助于解决移动和Web应用程序的常见开发功能。

The feature I’ll talk about is our Cloud DB, where you store and query user data. When we started to design Cloud DB, we asked ourselves how different apps store and query user data.

我将讨论的功能是我们的Cloud DB，您可以在其中存储和查询用户数据。当我们开始设计Cloud DB时，我们自问不同的应用程序如何存储和查询用户数据。

We looked at our company’s mobile apps portfolio for inspiration. Our company does everything from consumer apps to e-commerce apps. So we grouped them into “shoe-box” and “social” apps.

我们从公司的移动应用程序组合中寻找灵感。从消费类应用程序到电子商务应用程序，我们公司都应运而生。因此，我们将它们分为“鞋盒”和“社交”应用。

Shoe-box apps store personal data that the user wants to keep private. For example, our side project Spentable helps a user track of their daily spending. Data stored in the app is meant to be private, in a shoe-box.

鞋盒应用程序存储用户想要保密的个人数据。例如，我们的辅助项目Spentable可帮助用户跟踪他们的每日支出。应用程序中存储的数据是在鞋盒中私有的。

But, there is stuff that we want to share publicly or with friends. That also means the user needs to be in control of who can read their data. These two kinds of apps present a challenge in how we designed Skygear’s Cloud DB. We wanted to make storing data in Cloud DB as easy as possible. For shoe-box apps, all the developers need is a database where each user can only see the data that they are putting in. Yet, in social apps, developers need features such as ACL (access control). How can we make things simple for developers of both kinds of apps?

但是，有些东西我们要公开或与朋友分享。这也意味着用户需要控制谁可以读取其数据。这两种应用程序对我们如何设计Skygear的Cloud DB提出了挑战。我们希望使数据存储在Cloud DB中尽可能容易。对于鞋盒应用程序，开发人员所需的只是一个数据库，每个用户只能在其中查看他们所放入的数据。然而，在社交应用程序中，开发人员需要ACL(访问控制)等功能。对于两种应用程序的开发人员，我们如何使事情变得简单？

吃我们的蛋糕也吃 (Having our cake and eating it too)

We decided to solve this problem by introducing the concept of multiple databases in the Cloud DB: private DB and public DB. Each user has a private DB to put data in, and that data is only available to the same user. The app also has one public DB that is shared among all users.

我们决定通过在Cloud DB中引入多个数据库的概念来解决此问题：私有DB和公共DB。每个用户都有一个专用数据库来放入数据，并且该数据仅可用于同一用户。该应用程序还具有一个公共数据库，该数据库在所有用户之间共享。

A shoe-box app developer is able to focus on saving and fetching the data without worrying about permissions because data in the private DB is always private.

鞋盒应用程序开发人员能够专注于保存和获取数据而无需担心权限，因为私有DB中的数据始终是私有的。

But, private DB does not work at all for social apps. Developers for social apps should put data in the public DB because data in social apps are meant to be shared.

但是，私有数据库根本不适用于社交应用程序。社交应用程序的开发人员应将数据放入公共数据库中，因为社交应用程序中的数据是要共享的。

Before we added support for ACL, this simple distinction for public and private data served us(and our users very well. Everything in private DB is truly private while everything is public DB is truly public.

在添加对ACL的支持之前，对公共数据和私有数据的这种简单区分对我们(以及我们的用户)都非常有用。私有DB中的所有内容都是真正的私有，而公共DB中的所有内容都是真正的公共。

“Everything is public” is not good enough. Most social apps have use cases that data is only shared among a group of friends.

“一切都是公共的”还不够好。大多数社交应用都有用例，数据仅在一组朋友之间共享。

ACL is another difficult and interesting topic that should be it’s own article.

ACL是另一个困难而有趣的主题，应该是它自己的文章。

我们无法同时利用这两个数据库的优势 (We couldn’t have the best of both databases)

Separating the DB into private and public ones was a good idea. We thought they supported the use case for majority of apps.

将数据库分为私有和公共数据库是一个好主意。我们认为他们支持大多数应用程序的用例。

But early adopters found our private and public options confusing.

但是，早期采用者发现我们的私有和公共选择令人困惑。

Our early users gave us invaluable feedback. We also paid attention to the support questions we received. This is what we learned from developer feedback when they used our Cloud DB:

我们的早期用户给了我们宝贵的反馈。我们还关注收到的支持问题。这是我们从开发人员使用Cloud DB时的反馈中学到的：

It’s not obvious to developers what they’re building at first
对于开发人员而言，起初他们正在构建的东西并不明显

While it may be obvious which kind of app developer made by looking at the product retroactively, it is not obvious from the get-go. Forcing the developer to decide whether they are making a shoe-box or social app at the beginning is difficult, if not impossible.
回顾性地看待哪种应用程序开发人员可能很明显，但从一开始就并不明显。强迫开发人员决定一开始是制作鞋盒还是社交应用是困难的，即使不是不可能的。
Developers just want to get started quickly
开发人员只想快速入门

We want the developers to learn the basics as quickly as possible. Having to learn one more concept to choose which DB to use before they can actually save and retrieve data is too much to ask for new users.
我们希望开发人员尽快学习基础知识。在实际保存和检索数据之前，必须学习另一个概念来选择要使用的数据库，这对于寻求新用户来说实在太多了。
The decision for public or private DB, once made, isn’t easy to reverse
一旦做出公共或私有数据库的决定，就不容易撤销

Suppose that a developer started with a shoe-box app idea and they put everything in the private DB. Later they may realize that they should make the app a social one instead. It is not easy to migrate data once they are put into a particular DB.
假设开发人员从一个鞋盒式应用想法开始，然后将所有内容都放入了私有数据库中。后来他们可能意识到，他们应该改为使该应用程序成为社交应用程序。将数据放入特定的数据库后，迁移数据并不容易。
Permissions are usually an after thought
许可通常是事后的想法

Data security a priority in our company. But data security is not the first thing that comes to the mind of a developer. Especially when they’re just doing a proof-of-concept prototype. They want to focus on the functionality first, and take care of the security later on.
数据安全是我们公司的首要任务。但是，数据安全性并不是开发人员想到的第一件事。尤其是当他们只是在做概念验证原型时。他们想先关注功能，然后再注意安全性。

我们的外卖 (Our takeaways)

We are always thinking about how we could make our products better. We could do better in terms of software architecture, user documentation and ease-of-use. We sometimes brainstorm what we would do if we could rewind the clock two years to start over. But here is what we would tell our former selves:

我们一直在思考如何使我们的产品更好。我们可以在软件体系结构，用户文档和易用性方面做得更好。有时我们会集思广益，如果我们可以倒退时钟以重新开始两年。但是，这就是我们要告诉我们以前的自我：

If developers are already familiar with an existing concept, adopt it
如果开发人员已经熟悉现有概念，则采用它

Most developers are familiar with the concept of a database. It is a container of some sort where developers can save content. They can also retrieve data and support the CRUD (Create, Read, Update, and Delete ) property.
大多数开发人员都熟悉数据库的概念。它是开发人员可以保存内容的某种容器。他们还可以检索数据并支持CRUD(创建，读取，更新和删除)属性。

Because developers are already familiar with the concept of a database, they would find a single database on Cloud DB straight-forward to use.
因为开发人员已经熟悉数据库的概念，所以他们可以直接在Cloud DB上找到一个数据库来使用。
Introduce new concepts when developers are prepared for them
在开发人员为新概念做好准备时引入新概念

This idea is actually an other way of saying that we should make the learning curve as easy as possible. Skygear was a prototype in its own way. We just launched V
这个想法实际上是说我们应该使学习曲线尽可能容易的另一种说法。 Skygear本身就是一个原型。我们刚刚推出了V

1.0!.
1.0 ！。

You never want to make life for your early adopters difficult. Having to learn everything before developers can do anything does not work well from a product perspective. Until developers need to think about data permission, they should not need to know about the difference between a private DB and public DB. We should let our users get started with the common concepts first to familiarize themselves with a new platform.
您永远都不想让早期采用者的生活变得困难。从产品的角度来看，必须学习所有知识之后开发人员才能做任何事情。除非开发人员需要考虑数据许可权，否则他们无需了解私有数据库和公共数据库之间的区别。我们应该首先让用户开始使用通用概念，以熟悉新平台。

Only after they’re comfortable should we introduce new concepts to provide more options. In this case, there’s no harm for a developer to discover they need ACL so the new concept is a natural next step after they have learned how to use Cloud DB.
只有在他们感到舒适之后，我们才可以引入新概念来提供更多选择。在这种情况下，对于开发人员来说发现他们需要ACL并没有什么害处，因此，新概念是学习了如何使用Cloud DB之后自然而然的下一步。

我们学到了什么 (What we learned)

When we began working on Skygear two years ago, we wanted to build a kick-ass product with 2–4 of our senior developers. We had ready testers from our own in-house developers, who gave lots of critical feedback. We thought we were using our experience in web and mobile app development to make better decisions on how to design tools for other developers.

两年前，当我们开始从事Skygear的开发时，我们想与2-4位高级开发人员一起开发踢球产品。我们有自己的内部开发人员准备的测试人员，他们提供了许多关键的反馈。我们认为我们正在利用我们在Web和移动应用程序开发方面的经验来就如何为其他开发人员设计工具做出更好的决策。

But our experience also created assumptions about what to expect our users to know before using our product.

但是，我们的经验还为用户在使用我们的产品之前应了解的知识做出了假设。

The good thing about getting user feedback on Cloud DB as we went was that we learned that our assumptions were incorrect. Our most valuable lesson was the humbling reminder of a basic startup principle. No matter our experience, we often don’t know exactly what we’re building.

在进行过程中获得有关Cloud DB的用户反馈的好处是，我们了解到我们的假设是错误的。我们最有价值的一课是谦卑地提醒人们一个基本的启动原则。不管我们的经验如何，我们通常都不完全知道我们要构建什么。

Of course, that doesn’t stop us from trying to build that philosopher’s stone to make lives easier for our fellow developers anyway. As my co-founder, Ben, said one of his most productive days was when he tossed 1000 lines of code away.

当然，这并不能阻止我们尝试建立哲学家的石头，以使我们的其他开发人员的生活更加轻松。正如我的联合创始人本(Ben)所说，他最富有成效的日子之一是他丢掉了1000行代码。

I would like to credit my colleague cheungpat who worked on the Cloud DB with me and helped write this piece.

我想感谢我的同事cheungpat和我一起在Cloud DB上工作，并帮助撰写了这篇文章。

My team would love to hear your critical feedback for Skygear. Also check out our documentation and GitHub repos to see how we discuss Skygear features.

我的团队很想听听您对Skygear的重要反馈。另请查看我们的文档和GitHub存储库，以了解我们如何讨论Skygear功能。