This document discusses the transition from relational databases to NoSQL databases. It provides an overview of key-value databases like Tokyo Cabinet and how they provide high performance and scalability alternatives to SQL databases. It also describes how Tokyo Cabinet can be used with an ActiveRecord adapter to integrate NoSQL style databases into Rails applications, bridging the gap between SQL and NoSQL. Finally, it outlines a vision for further developing Tokyo Cabinet into a cloud database that can provide a unified interface to both SQL and NoSQL databases.

1. Ruby,NoSQL and TokyoCabinet 盛大创新院 庄表伟 http://www.zhuangbiaowei.com/blog/

2. From RDBMS to NoSQL (1) Long long ago … Network Database (GE IDS 1961) Hierarchical Database (IBM IMS 1968) Relational database era Edgar Frank Codd -- Since 1969 Relational model SQL Management system Over $ 20 billion (2008)

3. From RDBMS to NoSQL (2) Now is Web2.0 era Have huge storage(TB/PB data size) Need high performance Need high scalability Need high availability NoSQL now coming New theory support New API style New buzzword

4. Projects or papers… Google BigTable (2004) Tokyo Cabinet (2006) Amazon Dynamo (2007) MongoDB,CouchDB,Cassandra,Voldemort (2008) Redis,Riak,HBase… (2009) More and more… From RDBMS to NoSQL (3)

5. CAP (Eric Brewer 2000) Consistency Availability Partition tolerance BASE Basically Available Soft-state Eventual Consistency MapReduce From functional programming Distributed computing framework Important NoSQL theory

7. Any data is allowed

8. Can not ensure data consistency

9. Eventual Consistency

10. No transaction

11. Stored procedure convert to map/reduce script

12. Lack support of management system

13. System refactoring or rewriteChoose NoSQL means…

15. http://1978th.net/

16. TokyoCabinet -- lightweight database library

17. TokyoTyrant -- lightweight database server

18. Key/Value Database

19. Database types

20. Hash / B+ Tree / Fixed-length / Table

21. High performance

22. Insert: 0.4sec/1M records(2,500,000 qps)

23. Search: 0.33sec/1M records(3,000,000 qps)

24. High concurrency

25. High ScalabilityTokyoCabinet and TokyoTyrant

27. Loss table struct and data type

28. Can not access by column

29. Reduction of performance

30. Read 400,000 record/sec(TCT)

31. Read 1,800,000 record/sec(TCH)

32. Read 1,000,000 record/sec(TCB)

33. When the data more than 100 million, will performance reduction

34. Network protocol is not perfectTC/TT table engine insufficiency

36. Row access and column access

37. B+ tree data store

38. New binary api protocol

39. New data storage mode

40. Config TCH

41. Index  TCB

42. Data  TCBAbout TCDatabase

43. ActiveTokyoCabinet (1) Config

44. Model ActiveTokyoCabinet (2)

45. database.yml development: adapter: tcdb path: ./db database: blog model class Post < ActiveRecord::Base validates_presence_of :body, :title has_many :comments end About tcdb-adapter (1)

46. Migration class CreatePosts < ActiveRecord::Migration def self.up create_table :posts do |t| t.string :title t.text :body t.timestamps end end def self.down drop_table :posts end end About tcdb-adapter (2)

47. Demo

48. SQLite MySQL Oracle Money MySQL MySQL MySQL DBA RDBMS  NoSQL Risk RDBMS  tcdb-adapter  NoSQL SQL/NoSQL Bridge Storage architecture migration

49. Architecture diagram (today) Classic ActiveTokyoCabinet tcdb-adapter

51. Architecture diagram (future - 1)

52. Architecture diagram (future - 2)

53. Architecture diagram (future - 3)

54. It will be open source!

55. Thanks