cassandra

点击上方“朱小厮的博客”，选择“设为星标” 后台回复"书"，获取 来源：r6d.cn/r4P7 对比传统关系型数据库，NoSQL有着更为复杂的分类——键值、面向文档、列存储以及图数据库。这里就带你一览NoSQL各种类型的适用场景及一些知名公司的方案选择。 在过去几年，关系型数据库一直是数据持久化的唯一选择，数据工作者考虑的也只是在这些传统数据库中做筛选，比如SQL Server、Oracle或者是MySQL。甚至是做一些默认的选择，比如使用.NET的一般会选择SQL Server；使用Java的可能会偏向Oracle，Ruby是MySQL，Python则是PostgreSQL或MySQL等等。 原因很简单，过去很长一段时间内，关系数据库的健壮性已经在多数应用程序中得到证实。我们可以使用这些传统数据库良好的控制并发操作、事务等等。然而如果传统的关系型数据库一直这么可靠，那么还有NoSQL什么事？NoSQL之所以生存并得到发展，是因为它做到了传统关系型数据库做不到的事！ 关系型数据库中存在的问题 Impedance Mismatch 我们使用Python、Ruby、Java、.Net等语言编写应用程序，这些语言有一个共同的特性——面向对象。但是我们使用MySQL、PostgreSQL、Oracle以及SQL Server，这些数据库同样有一个共同的特性——关系型数据库。这里就牵扯到了

在上一篇文章中，我们和您一起了解了 vRouter的内部结构和进程 ，今天继续Tungsten Fabric其它组件的内部探秘旅程。 作者：Tatsuya Naganawa 译者：TF编译组 - control内部 - IFMAP-SERVER弃用 在R4.0之后，不建议使用ifmap-server，当前控制节点直接从cassandra接收配置信息。 https://github.com/tungstenfabric/tf-specs/blob/master/deprecating-discovery-4.0.md 话虽如此，但是在内部，它仍然使用ifmap结构来存储vrf、interface、logical-router等的拓扑数据。 为了直接从cassandra中拾取数据，对ifmap客户端进行了一些更改，这些更改由control使用。 https://bugs.launchpad.net/juniperopenstack/+bug/1632470 最初，ifmap客户端包含很多逻辑来从ifmap-server提取数据，但是目前它仅包含一种逻辑，从cassandra获取json文件，并用该数据填充ifmap结构。 https://github.com/Juniper/contrail-controller/tree/R2002/src/ifmap/client https:/

摘要： Gossip协议是Cassandra维护各节点状态的一个重要组件，下面我们以Gossip协议三次握手为线索逐步分析Gossip协议源码。 Gossip协议是Cassandra维护各节点状态的一个重要组件，下面我们以Gossip协议三次握手为线索逐步分析Gossip协议源码。 Gossip协议通过判断节点的 generation 和 version 来确认节点状态信息新旧，如果节点重启，则generation加一，version每次从零开始计算。所以 generation是大版本号，version为小版本号，理解这个概念对后面的握手逻辑有很大帮助。 Gossip协议最重要的一个属性是endpointStateMap ，这个map以address为key，以EndpointState为value维护节点自身状态信息。EndopointState 包含了节点 net_version,host_id,rpc_address,release_version,dc,rack,load,status,tokens 信息。总体来说，所有节点维护的endpointStateMap应该是一致的，如果出现不一致信息或者新增，替换，删除节点 ，这中间的状态维护就要靠Gossip来实现了。 另外一个重要属性subscribers ，当节点状态变更时候，gossip 会通知各个subscribers。