Cassandra can be used as an alternative to Memcache for caching data from a database in order to improve performance. Cassandra offers advantages over Memcache like persistence of data, horizontal scaling, and simpler management as a single database tier rather than separate Memcache and database servers. While Memcache is faster for in-memory operations, Cassandra can serve data both from memory using caching as well as from disk, and offers different configuration options for balancing performance, consistency and fault tolerance.

1. Cassandra as Memcache Edward Capriolo Media6Degrees.com

3. Main Memory - Fast

4. Hard Disks - Slow

6. 8 MB RAM

7. 1 GB Disk

8. 14.4kbps Modem

9. 686 Windowz 3.11

11. @ 4GHZ

12. 2GB RAM

13. 2TB Disk

14. 1/10Gb Ethernet

15. 64 bit FC 14

16. Sadly no more Packard bell

18. Until they take over and then they will be too fast and too big

20. Speaks some CGI alternative php|jsp|cfm|...

21. Logging

23. Stores and indexes data

24. Supports a data abstraction and manipulation language

26. id int auto_increment, name varchar UNIQUE,

27. pass varchar

28. )

29. create table book ( id int auto_increment, name varchar 25 unique, author varchar 25

30. )

31. Create table users_books ( uid int , bid int , unique (uid,bid), index (bid)

32. )

34. Totally random queries based on user login

35. Not often read - may not be helpful to cache

37. FROM user JOIN users_books

38. ON user.id=users_books.uid

39. JOIN book ON book.id=bid

40. WHERE user.id=?

41. More complex query

42. Two join conditions

43. Result might be on users start page

44. Result might be often used by algorithms

46. No where clause!

47. Possible table scan

48. Possible intermediate results to temp file

49. Result displayed on main index page

53. RAM not in use by a process

54. Used to Cache Disk

55. Blocks read often get cached in RAM

56. large disk to RAM ratio reduces hit chance

59. Does not add write capacity

61. Re-shard with growth

63. Works with memory slabs

64. Set a key, value, and a Time To Live

65. Typically client controlled sharing

67. If found in cache return

70. Saves web server memory vs HttpSession

71. Fast to store and access data

72. Simple to use

73. Clients for many languages

75. 8GB hash table better then 8GB more in your database machine?

76. Another tier to manage

77. Is it scalable?...

78. A highly un-suggested deployment

81. Linear Writes to sorted memtable

83. Bloom filters

84. Row Cache

89. Replication Factor = 3

90. Key Cache

92. Strong consistency

93. Highly fault tolerant

95. Replication Factor = 3

96. Row cache

97. Read Repair Chance = 0 %

99. Minor possibility of not found/out of sync data (not much different then memcache)

101. Replication Factor = 3

102. Row Cache

103. Read Repair Chance = 0%

104. Dynamic Snitches + Pinning

106. Caches on each node have less duplication

108. Replication Factor 20! (only this keyspace)

109. Row Cache

110. Read Repair Chance = 0%

112. Writes do not scale (like master-slave replication)

114. 0.7.X brings Read Repair Chance

115. Can serve purely from memory

116. Can serve from disk

117. Replication Factor, Caching, Sharding many ways to tune

118. General Awesomeness