Jepsen: ZK, NuoDB, Kafka, & Cassandra - YouTube

Jepsen: ZK, NuoDB, Kafka, & Cassandra - YouTube

I like this topic. However the video is just too lengthy and I don't have enough time to finish watching it. Just keep it here to watch later ( I don't really like YouTube's playlist feature ).

ZooKeeper Tutorial

http://springone2gx.com/blog/scott_leberknight/2013/06/distributed_coordination_with_zookeeper_part_1_introduction

Apache Camel: Loading routes from XML files

Quick Performance Test for Vertica on IEEE Floating Point Format Compression/Decompression Performance

I didn't think about it in this way before. But today I did some test and finally hit the performance issue. Surprisingly, it is not about I/O, but CPU.

I am planning to do a standard deviation calculation on some 4 million data item. Each data item has 50 columns, and 4,032 samples. So basically it need to handle 200 million data item, echo of which has about 4K samples.

I began my experiment with this and found out that it took me 39 minutes to finish the calculation. What? This calculation is supposed to run every 1 hour, and I probably going to handle 100 million data item, and possibly 50 K samples.

I suspected this was because Vertica has problem not to use enough memory to cache the intermediate result. I got more than 100G RAM on each of the Vertica node, but it only used 12G for the calculation. However, after I did a simple match, I found out it 12G was all it needed.

To verify this, I did the following two tests.

Test 2a: do the calculation on only one column. It took 3 minutes.
Test 2b: do the calculation on all columns but don't distinguish the data items. Which means the results will be 50 double values, instead of 200 millions values. It took 27 minutes to finish.

Obviously, this was not about how to use memory, but about traversing the data. When I looked into the result on Linux top command, it clearly showed me that CPU has big work load, which made the system load up to 30 or even 40 sometimes. My system has 24 CPU/cores, system load as 30 means full workload on the CPU/cores.

Google I/O 2009 - Transactions Across Datacenters..

http://www.youtube.com/watch?v=srOgpXECblk

2PC and 2PL

2PL

• Two-Phase Locking_程序设计之路的空间_百度空间
• 时间戳排序协议 - timestamp ordering protocol - TO 　Powered By SDCMS
• 2012年6月1日 随笔档案 - PromisE_谢 - 博客园
• 两阶段锁协议 - 使命召唤 - 博客园

2PC

• 两阶段提交协议（two phase commit protocol，2PC） - 张林林|深蓝(Linlin Zhang,shenlan211314) 的专栏 - 博客频道 - CSDN.NET
• [Oracle] 分布式事务和两阶段提交(2PC) - Zhu_Julian's Notes (朱显杰的技术博客） - 博客频道 - CSDN.NET
• 两阶段提交-2PC_周大_新浪博客
• 分布式事务中提到的2PC两阶段提交如何解决协调者在给多个参与者发送commit过程中宕机或者部分参与者在收到commit之前宕机的问题？也就是说部分参与者收到了commit,其他的参与者如何知道本次事务的最终结果？ - 知乎
• 两阶段提交(2PC)协议-jiangwen127-ChinaUnix博客

PAXOS

• Paxos算法 - 维基百科，自由的百科全书
• 3.7.2　Paxos协议 - 51CTO.COM
• 【自己动手实现一个分布式协调器之一】之理解paxos - 花考拉 - 博客园
• 两阶段提交协议与paxos投票算法-invincibleliu-ChinaUnix博客

Understand epoch of Vertica

• The Vertica Database Forums • View topic - What is an epoch exactly?

An epoch is associated with each COMMIT - the current_epoch at the time of the COMMIT is the epoch for that load. Vertica supports historical queries, though it's not a common use case for most customers. You can only query epochs that are after the current AHM, which is kept aggressively current by default. Deleted data prior to the AHM (Ancient History Mark) is eligible for being purged when a mergeout or explicit purge happens. After it's purged, delete vectors no longer need to be maintained. The Last Good Epoch is the epoch at which all data has been written from WOS to ROS. Any data after the LGE will be lost if the cluster shuts down abnormally from something like a power loss or a set of exceptions across multiple nodes. Refresh Epoch - don't worry about it, it doesn't get referenced in practice. 


dbadmin=> select current_epoch from system;
current_epoch 
---------------
44
(1 row)

dbadmin=> insert into epochs values(1); commit;
OUTPUT 
--------
1
(1 row)

COMMIT
dbadmin=> select current_epoch from system;
current_epoch 
---------------
45
(1 row)

dbadmin=> insert into epochs values(2); commit;
OUTPUT 
--------
1
(1 row)

COMMIT
dbadmin=> select current_epoch from system;
current_epoch 
---------------
46
(1 row)

dbadmin=> select * from epochs;
i 
---
1
2
(2 rows)

dbadmin=> at epoch 45 select * from epochs;
i 
---
1
2
(2 rows)

dbadmin=> at epoch 44 select * from epochs;
i 
---
1
(1 row)


dbadmin=> select make_ahm_now();
make_ahm_now 
-----------------------------
AHM set (New AHM Epoch: 46)
(1 row)

dbadmin=> at epoch 45 select * from epochs;
ERROR 2318: Can't run historical queries at epochs prior to the Ancient History Mark

Sharon Cutter
Independent Consultant for Vertica