跳到主要内容

关系数据库简介

· 阅读需 2 分钟

关系数据库是大多数存储使用案例的默认选择,原因在于 ACID(原子性、一致性、隔离性和持久性)。一个棘手的问题是“一致性”——它意味着任何事务都会将数据库从一个有效状态转变为另一个有效状态,这与 CAP 定理 中的一致性不同。

模式设计和第三范式 (3NF)

为了减少冗余并提高一致性,人们在设计数据库模式时遵循 3NF:

  • 1NF:表格形式,每个行列交集只包含一个值
  • 2NF:只有主键决定所有属性
  • 3NF:只有候选键决定所有属性(且非主属性之间不相互依赖)

数据库代理

如果我们想消除单点故障怎么办?如果数据集太大,无法由单台机器承载怎么办?对于 MySQL,答案是使用数据库代理来分配数据,可以通过集群或分片

集群是一种去中心化的解决方案。一切都是自动的。数据会自动分配、移动和重新平衡。节点之间互相传递信息(尽管这可能导致组隔离)。

分片是一种集中式解决方案。如果我们去掉不喜欢的集群属性,分片就是我们得到的结果。数据是手动分配的,不会移动。节点之间互不知晓。

价值的要素

· 阅读需 1 分钟

当客户评估一个产品或者一个服务时,他们会权衡==感知价值==和==实际要价==。

以下是30个“价值的要素”。

Elements of Value

  1. 功能性价值

    • 节约时间
    • 简化流程
    • 获取收益
    • 降低风险
    • 组织
    • 整合
    • 连接
    • 减少付出
    • 避免麻烦
    • 减少开支
    • 质量
    • 多样性
    • 感官诉求(如:食物与饮料)
    • 报信
  2. 情感性价值

    • 减少焦虑
    • 回报
    • 怀旧
    • 设计/美学
    • 徽章价值
    • 健康
    • 治疗价值
    • 愉悦/娱乐
    • 吸引力
    • 提供方法
  3. 改变生活

    • 给予希望
    • 自我实现
    • 动力
    • 传家宝
    • 联系/附属
  4. 社会影响

    • 自我超越

四种 No-SQL

· 阅读需 4 分钟

在一个常规的互联网服务中,读取与写入的比例大约是 100:1 到 1000:1。然而,从硬盘读取时,数据库连接操作耗时,99% 的时间花费在磁盘寻址上。更不用说跨网络的分布式连接操作了。

为了优化读取性能,非规范化通过添加冗余数据或分组数据来引入。这四种 NoSQL 类型可以帮助解决这个问题。

键值存储

键值存储的抽象是一个巨大的哈希表/哈希映射/字典。

我们希望使用键值缓存的主要原因是为了减少访问活跃数据的延迟。在快速且昂贵的介质(如内存或 SSD)上实现 O(1) 的读/写性能,而不是在传统的慢且便宜的介质(通常是硬盘)上实现 O(logn) 的读/写性能。

设计缓存时需要考虑三个主要因素。

  1. 模式:如何缓存?是读透/写透/写旁/写回/缓存旁?
  2. 放置:将缓存放在哪里?客户端/独立层/服务器端?
  3. 替换:何时过期/替换数据?LRU/LFU/ARC?

现成的选择:Redis/Memcache?Redis 支持数据持久化,而 Memcache 不支持。Riak、Berkeley DB、HamsterDB、Amazon Dynamo、Project Voldemort 等等。

文档存储

文档存储的抽象类似于键值存储,但文档(如 XML、JSON、BSON 等)存储在键值对的值部分。

我们希望使用文档存储的主要原因是灵活性和性能。灵活性通过无模式文档实现,性能通过打破 3NF 来提高。初创公司的业务需求时常变化。灵活的模式使他们能够快速行动。

现成的选择:MongoDB、CouchDB、Terrastore、OrientDB、RavenDB 等等。

列式存储

列式存储的抽象就像一个巨大的嵌套映射:ColumnFamily<RowKey, Columns<Name, Value, Timestamp>>

我们希望使用列式存储的主要原因是它是分布式的、高可用的,并且针对写入进行了优化。

现成的选择:Cassandra、HBase、Hypertable、Amazon SimpleDB 等等。

图数据库

顾名思义,这种数据库的抽象是一个图。它允许我们存储实体及其之间的关系。

如果我们使用关系数据库来存储图,添加/删除关系可能涉及模式更改和数据移动,而使用图数据库则不需要。另一方面,当我们在关系数据库中为图创建表时,我们是基于我们想要的遍历进行建模;如果遍历发生变化,数据也必须随之变化。

现成的选择:Neo4J、Infinitegraph、OrientDB、FlockDB 等等。

买家角色为什么重要?

· 阅读需 2 分钟

KYC 并不容易

==您有多少机会听到客户描述他们的问题?== 如果您是大型公司的非营销部门员工,答案可能是从未。

如果您确实有机会,买家角色概念的核心有两点,==

  1. 提问
  2. 倾听

==KYC(了解您的客户)== 并不容易。例如,2008年,iPhone 3G在日本的销售情况不佳。日本客户习惯于使用手机拍摄视频/用借记卡芯片支付/使用通勤卡芯片。

买家档案很好,但还不够

一个通用的买家档案无法让营销人员准确了解决定买家购买决策的因素。营销人员只是根据人口统计信息(年龄、收入、婚姻状况、教育程度)或心理特征(个性、价值观、生活方式、观点)进行猜测。

不过,买家档案仍然可以提供一些明显的答案。例如,通过电子邮件活动联系首席财务官是非常困难的。强调汽车货舱的宽敞对于只养金鱼的忙碌女性来说并没有用处。

与其猜测,构建买家角色的最有效方法是采访那些之前权衡过选择、考虑或拒绝过解决方案并做出与您想要影响的决策相似的买家。

买家角色 = 买家档案(谁会购买) + 买家洞察(何时/如何/为什么购买)

在市场营销中,CAC,LTV,PBP是什么?

· 阅读需 1 分钟
  • CAC(用户获取成本): 用户获取成本是指使顾客购买产品或服务的成本。
  • LTV(用户的终身价值): 用户终身价值是指我们可以从客户那里获得的净利润。
  • PBP(回收期): 资本投资的回收期是指收回投资成本或达到盈亏平衡点所需的时间。理想的回收期约为一年。

LTV:CAC 比例

LTV:CAC 比例帮助你确定你应该花费多少成本去获取一名客户,以便实现可持续增长。

  1. 1:1 = 卖得越多赔的越多。
  2. 3:1 或更高 = 很好。
  3. 5:1 或更高= 市场营销上的投入做得不够。

非暴力沟通 (NVC)

· 阅读需 2 分钟

为什么选择非暴力沟通?

通过 ==重视每个人的需求== 来改善沟通质量。 ==判断和暴力是未满足需求的悲惨表现。==

NVC 不是

  • 不是关于友好的。
  • 不是让他们做我们想要的事情。这是关于相互理解。

增强连接与理解的方法:

  1. 脆弱地表达我们的感受和需求
    • 对持续的感受和需求的意识
    • 暴露感受和需求的脆弱性
  2. 同情地倾听对方的感受和需求。
    • 同情倾听的品质:在场、专注、空间、关心,==对感受和需求的言语反映==
    • 不是建议、修复、安慰、讲故事、同情、分析、解释等。
    • 无论说什么,只听感受、需求、观察和请求

例如:==你是因为需要……而感到……吗?==

使我们彼此疏远的方法

  • 诊断、判断、标签、分析、批评、比较等。
  • 应得思维(即某些行为应受到惩罚或奖励)
    • 要求(否认他人的选择;意图惩罚那些不这样做的人)
    • 否认选择或责任(不得不、应该、被认为、他们让我这样做等。)

布隆过滤器

· 阅读需 2 分钟

布隆过滤器是一种数据结构,用于以时间和空间高效的方式检测一个元素是否在一个集合中。

可能会出现假阳性匹配,但不会出现假阴性——换句话说,查询返回“可能在集合中”或“绝对不在集合中”。元素可以添加到集合中,但不能移除(尽管可以通过“计数”布隆过滤器来解决这个问题);添加到集合中的元素越多,假阳性的概率就越大。

使用案例

  • Cassandra 使用布隆过滤器来确定 SSTable 是否包含特定行的数据。
  • HBase 布隆过滤器是一种有效的机制,用于测试 StoreFile 是否包含特定行或行-列单元格。
  • 网站的反欺诈系统可以有效地使用布隆过滤器来拒绝被禁止的用户。
  • 谷歌 Chrome 浏览器曾经使用布隆过滤器来识别恶意 URL。

跳表

· 阅读需 1 分钟

跳表本质上是一种链表,允许您在其上进行二分查找。它通过添加额外的节点来实现这一点,使您能够‘跳过’链表的某些部分。通过随机投掷硬币来创建额外节点,跳表的搜索、插入和删除操作的时间复杂度应为 O(logn)。

用例

  • LevelDB MemTable
  • Redis SortedSet
  • Lucene 倒排索引

跳跃表

· 阅读需 1 分钟

跳跃表本质上是一个允许对其进行二分搜索的链表。它实现这一点的方法是添加额外的节点,使你能够“跳过”链接列表的部分。对于给定一个正反随机数来创建额外的节点,跳跃表具有O(logn)复杂度的查询、插入和删除。

用例

  • LevelDB MemTable
  • Redis 有序集合(Redis SortedSet)
  • 倒排索引(Lucene inverted index)

布隆过滤器

· 阅读需 2 分钟

布隆过滤器(Bloom filter)是一种数据结构,用于以远高于其他一般算法的空间和时间效率来检索一个元素是否在一个集合中。

使用布隆过滤器获得的结果,可能为假阳性匹配,但是不可能为假阴性匹配。换句话说,查询返回的结果是“==要么在可能不在,要么不在肯定不在==”。元素可以添加到集合中,但不能删除(尽管这可以通过额外的“计数”布隆过滤器来解决);添加到集合中的元素越多,误报的可能性越大。

用例

  • Cassandra使用布隆过滤器来确定SSTable是否有特定行的数据。
  • HBase布隆过滤器是一种测试StoreFile是否包含特定行或者行列单元格的有效机制。
  • 使用布隆过滤器,网站的反作弊系统可以有效地拒绝被禁止使用的用户。
  • 谷歌的Chrome浏览器曾使用布隆过滤器来识别恶意链接。