在分布式大数据存储系统中，有三种类型的数据需要存储：结构化数据、半结构化数据和非结构化数据。这些数据种类的存储方式也有所不同。结构化数据通常用二维表结构存储，并使用分布式关系数据库进行存储和查询。半结构化数据介于结构化数据和非结构化数据之间，常常采用键值对形式来表示，并使用分布式键值系统进行存储和使用。非结构化数据则是数据之间关联不大的数据，如文本内容、报表和视频等，通常使用ElasticSearch进行检索。
在分布式存储系统中，数据的时间戳是一个重要的概念。时间戳可以用于对数据进行版本控制。在Bigtable中，每个数据都可以存储多个版本，不同版本用时间戳索引。时间戳是64位整数，可以由Bigtable指定，这种情况下就是毫秒级的真实时间戳；也可以由客户端应用指定。如果是应用指定，那为了避免冲突，应用必须保证时间戳的唯一性。
在设计分布式存储系统时，需要考虑到系统可能会面临各种故障。故障源比我们想象的要多得多，除了网络分裂和出错后停止服务之外，还可能会出现内存和网络损坏、机器死机、时钟偏差、更复杂和非对称的网络分裂、依赖的基础服务的bug、GFS配额溢出、计划和非计划的硬件维护等故障。因此，在设计分布式存储系统时，需要修改各种协议来应对这些问题，例如给RPC机制添加校验和。
在分布式存储系统的设计中，保持设计的简洁是非常重要的。当设计变得过于复杂时，很可能导致怪异的边界场景的出现，从而增加debug的难度。因此，需要不断地重新设计和改进协议，使其更加简单、稳定且易于维护。
压缩在分布式存储系统中也是一个很重要的问题。在Webtable中，存储了大量的页面进行了一次实验。实验中每个页面只存储了一个版本。结果显示，Bentley-McIlroy算法的压缩比达到了10:1，而典型情况下Gzip压缩HTML页面只有3:1或4:1的效率。这么高的压缩效率来自Webtable的行组织方式：来自相同域名的页面都存储在一起。这些页面有着很多类似内容，非常适合Bentley-McIlroy算法。如果数据是存储了多个版本而不是一个版本，那压缩比会更高。
在设计分布式存储系统时，需要避免过早添加使用场景不明确的新特性。如果还不是非常清楚一个新特性将被如何使用，那就不要着急添加到系统中。例如，Bigtable最初有计划在API中支持广义事物模型，但因为当时没有迫切的使用场景，因此没有立即去实现。现在有了很多真实应用跑在Bigtable之后，我们审视了这些应用的真实需求，发现大部分应用其实只需要单行事务。对于真的有分布式事务需求的人，我们发现他们最核心的需求其
