大家好
感谢大家加入我的在线虚拟盛会
我知道我们原本的演讲标题是
Firebase中后端游戏 开发人员的新鲜事
但是，嘿，剧透警报
我们将讨论Cloud Firestore 它到底是什么
为什么你应该要知道它
以及为什么旁边的数据库 工程师会那么兴奋
你可能听说过，Firebase
有许多工具可以帮你轻松地
启动和运行游戏
总体思路是，嘿，为什么
不让我们处理无聊的 基础架构工作？
你可以专注于其他任务
例如使游戏变得有趣
这也许应该是你的首要任务
我们提供了Firebase 身份验证之类的服务
这使你的用户可以非常轻松地
从各种不同的提供商处登录游戏
我们有Firebase托管
我们可以使你轻松地
在默认为SSL的
全球CDN上启动网站
并快速运行
例如，如果你有一个 一次性的营销网站
想要快速托管游戏 那么这真是太好了
我们有Cloud Storage 这是一项功能强大但简单的服务
用于存储大型二进制物件
这可能是用户生成的内容
如屏幕截图或视频 也可能是你提供的内容，例如
大量的安装后游戏数据
有适用于Firebase的云功能
可让你从根本上运行后端代码
而无需自己支撑任何服务器
我们有在云中存储数据的数据库
现在，实时数据库 是许多开发人员
都听说过的数据库
这是Firebase在自己
独立创立公司时的旗舰产品
而且它仍然是一个很棒的产品
如果用户更改一台设备上的值
我们服务器中的SDK
会在侦听该值的其他所有设备上
自动更新
是的，我应该提醒一下 此处的实时性
与你的游戏开发人员 所习惯的实时性
不太一样
这是几百毫秒的延迟
因此可能不太适合 为第一人称射击游戏供电
但是你完全可以用它 来驱动宾果游戏
实际上，这是一个有趣的事实
实时数据库为Loteria供电
这是像Google Doodle 一样的宾果游戏
它在十几个国家的 Google首页上运行
实时数据库负责
对接会，召唤方格
实时显示对手的举动
并宣布获胜者
而且真正棒的是
当我们开始在Google首页上
显示该游戏时 该游戏的玩家在一夜之间
从零变成了数百万人
原来Google吸引了 很多流量，谁知道呢？
而实时数据库处理了这一切
没有给工程师或其他任何人 带来惊慌的电话
实际上，我们有一篇 非常不错的博客文章
详细介绍了工程团队 如何完成所有工作
我鼓励你读一读以获取更多信息
那文章很不错
但是，对于许多app和Web开发人员
我们推出了下一代的
实时数据库，这个产品
称为Cloud Firestore
总而言之 它是一个非常受欢迎的产品
除了到目前为止还没有C+ 或Unity的客户端库
或者我猜是几周前我们宣布
将其作为Alpha版本提供时
我将在稍后谈论更多 有关Alpha标签的信息
因为这很重要
现在，也许有一些人 对此感到非常兴奋
并开始建立自己的
复合索引
但是对于那些 不是数据库专家的其他人
你可能会问自己，好吧
我想这全都是好消息
但这到底是什么意思？
我为什么要在乎呢？
让我们回头进行解释
像实时数据库一样 Cloud Firestore
是NoSQL数据库的 数据库家族的一部分
如果你想要
过度简化的版本
请你考虑一下传统数据库
你有一堆表，每个表
都存储高度结构化数据的类型
你可以使用SQL的查询语言
将这些数据位连接在一起
你可以在这里做很多 有趣的事情，对不对？
你可以合并各种表格中的
不同数据或计算
所得的数据
尽管这很好用，但性能
的变化很大
此查询可能需要很长的时间 或很短的时间
具体取决于我拥有多少数据 设置的方式
以及我要什么样的查询
现在，NoSQL数据库 在一些重要方面
有所不同
你会注意到的一件事是
它们的数据往往显得有些松散
这被正式地称为无模式
这通常被视为一件好事
它使开发人员能够更快地迭代
其基础数据
而不必担心会回填
他们对所有较旧记录
所做的每次更改
它还使你能够存储相似
但不完全相同的数据
你可以在这里看到 我在同一集合中
一起存储了一堆字符
是的，当然，它们是相似的
但是我可以继续为法师 添加一本咒语书
为我的战士添加战斗声
并为小偷设置一个锁扣
而且我们的数据库不会抱怨
我们的数据结构从一个字符
到另一个字符并不完全相同
它可以解决这个问题
但是我认为NoSQL数据库的
最大区别在于没有SQL
查询往往要简单得多
你无法得到所有数据
或计算所得的数据 合并在一起的精美联接
这意味着你一开始经常会看到
有些奇怪或不寻常的事物
例如在多个位置存在相同数据的副本
现在，其中的一些怪癖 特别是这里的这个概念
称为d标准化数据
最初使长期的SQL开发人员感到惊讶
但是从长远来看 有一些非常不错的折衷
使这些怪异值得
首先，NoSQL数据库可以水平扩展
这真的很棒
这基本上意味着，随着你的数据集
变得越来越大，你可以在其中
投放越来越多的电脑
它将继续进行，并简单地 在所有这些不同的电脑上
提供数据
在云托管环境中
这确实很有用，例如
Google Cloud Platform 这里有大量的服务器
我们可以根据你的数据库需要 随时打开和关闭服务器
你的数据库只是在后台成长
并扩展到这些不同的服务器上
而你甚至不知道我们正在为你
完成所有这些工作
相比之下，传统的SQL数据库
倾向于垂直扩展
这意味着随着数据集的增长
你需要找到越来越多的电脑
来进行托管
这可能会有问题
一方面，在某个时候
你可能会用完大型超级电脑
来运行数据集
这也意味着每次
你需要切换到更大更快的超级电脑时
都可能会出现一些停机时间
通常在NoSQL数据库中
你会发现更好的性能
实际上，在Cloud Firestore世界中
我们喜欢的是
查询扩展到结果集的大小
而不是基础数据集的大小
那是什么意思呢？
这表示，例如，你有一个游戏
其中将用户生成的谜题 存储在Cloud Firestore
且你要求数据库向你发送
按评分排序的
美国前十大活动级别 该查询将采用
是否需要搜索300条记录
或3亿条记录的时间相同，对吗？
不管基础数据集有多大
此查询基本上将花费相同的时间
这非常棒，因为这意味着
随着游戏越来越受欢迎
你通常不必出于性能原因
而不得不重组数据库
让我们看一下其他一些功能
这些功能通常使Cloud Firestore
令人使用愉快
对于初学者而言 数据结构模型
往往非常易于使用，尤其是
与诸如实时数据库或其他NoSQL
数据库之类的模型相比
你的所有数据都倾向于
存储在文档和集合中
现在，你可以将文档
视为包含键值对的文档
这些东西的值
可以是任何值，从数组到字符串
到浮点数到JSONy对象，甚至是
少量的二进制数据都可以
现在，每个文档最多可以包含
1兆字节的数据，考虑到你在这里
主要处理文本和数字 以及JSONy内容
实际上这是非常大的
现在，这些文档存储在集合中
你可能会怀疑它们是文档的集合
这些文档可以且经常
指向包含其他文档的子集合
这些子集合甚至可能指向其他子集合
依此类推
现在，这里的一个重要说明是 所有查询都是浅层的
这意味着你可以获取文档
而不必担心获取其下面的所有数据
这意味着你可以按逻辑上合理的方式
对数据进行分层结构
而不必担心每次你的用户
在此处请求这些文档之一时
都会获取大量不必要的数据
Cloud Firestore在所有客户端库中
都内置了真正强大的离线支持
因此，当你从服务器获取数据时
SDK会自动缓存你的数据
然后，如果你要上新飞机
打开飞机模式，他们仍然可以访问
设备上缓存的所有数据，这意味着他们
可以继续玩游戏
你可以继续查询离线缓存中
存储的所有数据
此外，玩家播放的任何内容
都会在设备上排队
然后，一旦用户重新联机
他们就会按照记录的顺序
传送到你的数据库中
因此，他们的游戏会话数据都不会丢失
Cloud Firestore支持简单的一次性
数据获取，如果你来自
更传统的数据库，这可能是你
惯用的方式
许多开发人员开始以这种方式 使用Cloud Firestore
但是你也可以添加实时侦听器
以便在文档中的值发生更改时
立即通知你的客户端
很棒吧？
你只要告诉图书馆，嘿
我想知道这个查询的结果
当这些值更改时
Cloud Firestore可以向你 发送更新，这意味着
你无需处理任何拉动
即可刷新废话
你的新数据将立即显示
这对于多人游戏等情况
非常有用，当你希望在用户轮到他们后
更新游戏状态时，这种情况非常有用
Cloud Firestore具有多区域支持
这意味着我们可以将你的数据
存储在彼此相距几英里的不同位置
从可靠性的角度来看，这确实很棒
因为，假如有某种放射性蜥蜴
或什么东西使整个城市离线
你仍然可以从其他区域
访问你的数据
但是同时，它是非常一致的
这意味着无论你的客户端
最初对哪个区域进行ping操作
你正在检索的数据都是已写入数据库的
最新数据版本
我说实话
有了这种多区域支持，同时
又保持高度一致
我们在幕后为你解决
非常奇妙而困难的问题
老实说，我认为人们不会真正
欣赏它的酷炫之处
所以当我说，嘿 这是我们解决的一个问题
请相信我
如果你要确保其他客户端
不会在同一时间弄乱你的数据
Cloud Firestore也支持原子交易
我没有幻灯片
但是我知道这是人们关心的事
我要在这里提及
由于我们都在制作游戏
我们知道我们不能一直信任客户
因此我们也支持云功能和安全规则
现在，安全规则是你定义的规则
它将拒绝来自客户机的请求
这些请求要么是客户机 正在请求的数据
要么是客户机正在试图写的数据
这些数据看起来不符合你的期望
但是，如果你需要更复杂的控件
你可以使用Cloud Functions
这些是无服务器功能
可以在你控制和信任的环境中
在云运行
这意味着你可以确保此功能
在所有客户端中都一致
更重要的是，你信任
它们对数据库所做的更改
因此，我知道我们已经谈论了 很多关于Cloud Firestore的信息
Cloud Firestore 是我们实时存在于云上的
NoSQL数据库
你可能会问自己，好吧，等一下
这与Firebase实时数据库，也就是
驻留在云的实时数据库 相比如何呢？
我需要明确指出，你不需要
选择任何一个
你可以根据需要在同一个项目中
同时使用两者
但是，如果你需要对两者 进行比较和对比
我通常会喜欢将Cloud Firestore视为
实时数据库的重型版本
总的来说，我认为它可以 更好地处理更复杂的
数据
这是我个人的看法
但是我认为数据模型更易于使用
你有更强大的查询功能
你的交易更加复杂
它的扩展性甚至比实时数据库更好
而且，你具有多区域支持以提高可靠性
不过，有一些事可以使实时数据库
更好
如果你的客户位于北美
并具有内置的在线支持 则往往会更快一些
这是很多游戏开发人员 所关心的事情
某种程度上是让玩家找出 他们的朋友是否在线
现在，存在针对此问题 和Cloud Firestore的解决方法
但这不是本机内置的
它不如实时数据库
优雅
此外，定价模式也不同
在实时数据库中，你的费用
主要基于你要来回
发送给客户的数据量
Cloud Firestore的成本主要基于
你执行的读取或写入操作的数量
因此，总的来说，当你进行
许多小型操作时，实时数据库
将更具成本效益
想像一下宾果或扑克之类的游戏
你的客户经常发送
很少的信息
例如跟注、加注或B14
当你进行少量的大型操作时
Cloud Firestore往往更具
成本效益
考虑一下异步绘画游戏
你可能会在其中发送表示玩家绘画的
大量JSON数据，或者甚至
是基于回合的单词 或象棋游戏在这种情况下
玩家往往需要思考很长一段时间 才能思考转一转
他们没有执行那么多操作
但是我也想说，不要太执着价格
Cloud Firestore有很多方法
可以使你的生活更轻松
而且你知道，你的工程时间也要花钱
如果要花10个额外的工程小时
才能为自己节省 18美元的服务器成本
那可能不是正确的权衡
明智地使用你的工程时间
这些人倾向于更爱高档小吃
那么你将如何在现实生活中 使用Cloud Firestore？
让我们看看现实世界中 一些可能的使用场景
最简单的用例之一--
将玩家的游戏保存到云端，对吧？
你的用户想要在多台设备上玩游戏
Cloud Firestore将游戏状态
保存到云中变得非常容易
只需将播放器状态写入文档
然后将该文档写入数据库即可
其他倾听该价值的客户
都可以获取最新版本
并确保玩家的进度在他们玩游戏的
任何地方都能得到体现
我还应该指出，与实时数据库相比
Cloud Firestore的存储
相对便宜
因此，你可以继续保存一些版本
当你是玩家时，疯狂地
打电话给客户支持 而他们表现得好像是
我的游戏有问题
你可以选择将其还原到 较早的保存游戏
Cloud Firestore的另一个 好用例是共享游戏状态
考虑回合制文字游戏或绘画游戏
对于初学者来说，让客户
继续并查询其参与的游戏确实非常容易
然后，每当你的玩家想要转弯时
你都可以在此共享文档中 记录该新游戏状态
所有合适的玩家都可以访问
该状态
然后，借助实时侦听器的魔力
这些其他玩家的客户可以在游戏状态
更改后，立即进行更新
他们知道该轮到他们了
如果你需要额外的安全性
而不是让客户直接更新此文档
则可以让他们将所需的操作
中继到Cloud Function
请记住，这些是我们在云中的
无服务器功能
该Cloud Function 可以验证玩家的移动
确保一切看起来合法
然后，它可以执行实际更新
共享游戏状态的工作，然后
将其发送给其他玩家
由于我们与Firebase
Cloud Messaging集成
你可以向其他播放器发送通知
这样一来，即使他们 目前没有打开你的应用
他们仍然可以收到轮到他们的警报
日常挑战，这些可能是 另一个很好的例子
这些东西都是相当不错的内容
你需要在每次客户登录时
将其发送给所有客户
我知道有很多角色扮演游戏、益智游戏
填字游戏等等，这些游戏每天都有挑战
这是可以通过Cloud Firestore
轻松存储和提供的数据
用户生成的内容 也可能是一个很好的用例
同样，对于大型二进制物件 例如视频或屏幕录像
我建议使用Cloud Storage
但是，请考虑用户创建自己关卡的
任何益智游戏或平台游戏
这可能是你存储为JSON的数据
这些可以在Cloud Firestore中 很好地工作
你可以再次运行类似的查询
找到按评分排序的 北美地区创建的所有难题
或者找到最新的难题，或者找到
特定作者的所有难题
但我认为，从政治上来说
许多大型公司和更老牌公司
最有趣的用例是将Cloud Firestore
用作当前基础架构之上的 实时全局可扩展缓存层
让我们看一下航空公司
在这些航空公司中，他们拥有 30年历史的旧服务器
内置了许多业务逻辑
和法规遵从性
他们可能无法将所有内容交换到
全新的NoSQL数据库，对吧？
但是同时，也许他们想要一个 很好的现代应用程序
基础结构，它可以处理数百万个查询
并具有实时更新和良好的离线支持
以及所有这些奇特的东西，对吗？
这些企业可以做的就是将
部分数据复制到 Cloud Firestore实例
这使这些客户真正方便地
进行搜索，例如，查找机票价格
或获取航班状态信息 或诸如此类的东西
并实时获取这些更新
同时让你的旧服务器处理重要的事
例如，买票，可能仍然需要通过
原始服务器的内容
如果你一直在观看此视频
我想你没有航空公司可以运营
但是也许你有MMO 可收藏的纸牌游戏
或角色扮演游戏，其中拥有大量数据
无论这是游戏平衡设置
玩家个人资料，或是客户想要
定期阅读的东西
再说一遍，有很多客户端一直在
攻击你的服务器
因此，可以考虑将Cloud Firestore 放在最前面
对吧？
你的客户可以继续查询你推送到
Cloud Firestore的数据，同时
让原始服务器可以自由
处理重要事务，例如玩家交易
或用户购买
话虽这么说，也许你
为使用Cloud Firestore 开始构建而感到非常兴奋
但是我确实想在这里 谈论Alpha标签
尽管Cloud Firestore后端服务
已经存在了很长时间
并且已在实际的app中使用
但是这些新的客户端库是非常新的
并且尚未经过实际测试
因此，请期待错误
可能会有一些
我们知道Unity SDK中
缺少一些高级功能
一些更复杂的查询尚不可用
而且尚不支持数字转换
之类的功能
我们完全预计API的面貌
将在未来几个月内发生变化
在更新客户端库时
你将不得不在某个时候
为方法重新命名
我鼓励你开始尝试
这些新库
了解它们如何适合你的游戏基础架构
当然，请向我们发送反馈
但是，也许要等到几个月之后
才能将你的整个业务转移到 Cloud Firestore
因此，有了这个免责声明
我希望我们至少对你在最新游戏中
使用Cloud Firestore有一点兴趣
如果你想了解Cloud Firestore
或更多和我们其他服务的相关信息
请访问firebase.google.com/games
感谢收看