• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Taming Cassandra
 

Taming Cassandra

on

  • 1,183 views

 

Statistics

Views

Total Views
1,183
Views on SlideShare
1,145
Embed Views
38

Actions

Likes
2
Downloads
22
Comments
0

3 Embeds 38

http://www.jug.lv 31
http://www.linkedin.com 5
http://jug.lv 2

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • 150 tomcats\n
  • 150 tomcats\n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • \n
  • \n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • \n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • \n
  • \n
  • \n
  • \n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n
  • В работе SQL серверов, хранящих метаданные по фотографиям и связанные сущности(оценки, решения модераторов), наблюдаются проблемы: повышенная нагрузка, повышенная дисковая очередь, ухождение процесса в область подкачки (swap), падения(в том числе многократные), "синий экран смерти".\n

Taming Cassandra Taming Cassandra Presentation Transcript

  • Taming Cassandra@ odnoklassniki.ruby Oleg AnastasyevLead Platform Dev
  • 5M users online250 000 pages/s, 50 ms >100 Gbit/s ( >2x growth last year)> 4000 servers in 4 DCs 99% java
  • Data Storages we use• MS SQL 2005• Berkley DB based solution• Voldemort + Tarantool• Cassandra forked since 0.6 at 2010
  • cassandra @ odnoklassniki• Social graph persistent store• Like AKA “Класс!” button servers• Photo Marks storage• ... and number of others in development
  • Intro to cassandra (oversimplified)
  • Cassandra : ring 00 Gossip: ★ Cluster membership192 64 ★ Failure detection 128
  • Cassandra : partitioningPartitioner.toStringToken(key) : Token 00RP: Token=md5(key)OPP:Token=toString(key) Data Range 192-00 Data Range 00-64 192 64 Data Range 128-192 Data Range 64-128 128
  • Cassandra : replicationReplicationStrategy: 00Token => InetAddress• Simple•RackAware R1 192 64 R3 128 R2
  • Cassandra : writes Tunable Client 00 consistency level: CL = ZERO CL = ONE THRIFT CL = QUORUM CL = ALL Row Mutationerror if# writes < CL 192 64 Hint Storage 128
  • Cassandra : reads Client 00 Data resolved result Hash 192 64 Wrong HashTunable consistency:CL = ONECL = QUORUM BackgroundCL = ALL Read Repair 128
  • Cassandra: data model Keyspace (“Database”) 1..* ColumnFamilyStore (“Table”) << dynamic >> 0..* ColumnColumnFamily 0..*(“Row”) name : byte[] << dynamic >> value : byte[]key : String timestamp : long
  • Cassandra: local write(s) name value ts Write (Key, Column) Commit Log Memtable Flusher Thread flushes SSTable 1 SSTable 2 SSTable 3 SSTable 4 Merge-Sorted Compaction Thread SSTable 5Writes are always sequential!
  • Cassandra: local read(s) name value timesta (part of) data mp resolve Memtable SSTable 1 SSTable 4 SSTable 5• get(Key, columnNames[])• slice(Key, from, count, direction)• key_range(from,count)
  • SSTable anatomy SSTable-5-Filter.db SSTable-5-Index.db SSTable-5-Data.db Bloom Filter Row Columns Key => Offset Per Row Bloom Filter“Row May Exist” Per Row Index False Positives So: - ZERO reads, if row is missing AND you’re lucky - 1 seek and read of index, if row is missing AND you’re not - 2 logical seeks per read (for small rows) - 3 logical seeks per read (for large ones)
  • Conflict ResolutionSSTable “AccStatements-3456” MemtableRowKey = “Oleg_Anastasyev” RowKey = “Oleg_Anastasyev”ColumnFamily = “AccountStatements” ColumnFamily = “AccountStatements”Column=”LV05HABA95142357516”Value= $1,000,000 vs Column=”LV05HABA95142357516” Value= $10 Which data is correct ?
  • Conflict ResolutionSSTable “AccStatements-3456” MemtabeRowKey = “Oleg_Anastasyev” RowKey = “Oleg_Anastasyev”ColumnFamily = “AccountStatements” ColumnFamily = “AccountStatements”Column=”LV05HABA95142357516”Value= $1,000,000 vs Column=”LV05HABA95142357516” Value= $10Timestamp = 1.1.2012 00:00:00 Timestamp=2.2.2011 00:00:00 The one with latest timestamp. period.
  • Missed Update problemClient 1 Client 21. Read AccountStatement for Key=”Oleg” 1. Read AccountStatement for(got $10, TS=12:00:00) Key=”Oleg” (got $10, TS=12:00:00)2. Deposit $1,000,0003. Save Key=”Oleg”, 2. Withdraw $1 Value=$1,000,010 TS=12:00:01.00 3. Save Key=”Oleg”, Value=$9 TS=12:00:01.005 Distributed counters (since 0.7) ! No generic solution for Read-Modify-Update !
  • Intro SummaryPros: Cons:• No SPoF • No ACID, No rollbacks• Focus on Availability • No conflict detection• High and Stable Write performance • No locks• On the fly cluster expansion • NoSQL => Think ahead for queries• Very efficient missing row read• No locks• No backups necessary• Instant Multi DC
  • Tired of RTFM ?
  • Ok. Here is the problem
  • Ok. Here is the problem
  • Ok. Here is the problem
  • Ok. Here is the problem• PhotoMarks tablePhotoId:long UserId:long OwnerId:long Mark:float timestamp9999999999 1111 2222 1.0f 11:00 – 2 billion shows a day (~ 50 000 on peak second) – 100 mi new marks on 10 M new photos a day ( ~ 2500 a second ) – 1.5 Tb of data + 800 Gb indexes and growing + 3 Gb per day• Query patterns – EXISTS ( PhotoId=?, UserId=?) - for 98% of calls answer is “NOT EXISTS” – SUM(), AVG() on PhotoId=? -- what are totals on photo ? – OwnerId=? ORDER BY Timestamp DESC -- who marked my photos ? – COUNT(*) OwnerId=? AND Timestamp>? -- how many new marks are ? – UserId=? --for cleanup
  • And the trouble is– 32 SQL clusters are serving it (not counting stanby’s)– ... and they are close to their capacity in CPU, disk array iops
  • Simple solutions ?• Add more SQL nodes – There are already 32 of them, add more 32 => 64 – Expensive (hardware + software) – Extension is offline and a lot of manual work – Repeat in half a year ( => 128 => 256 )• Memory cache – High NOT EXISTS queries render LRU cache useless – So you have to cache 100% of rows – 1.5Tb of RAM is not cheap – and you need 2-3x more for fault tolerance and queries
  • Cassandra !• Leveraging Pros – Cheap NOT EXISTS ( bloom filter powered ) – CFs are enough to model this – Data are stored on disk together (most queries are 2 disk reads) – Cold dataset is stored on disk – On the fly expansion of cluster – Strong Availability• Not hitting Cons – No ACID requirements – Eventual Consistency is ok – Marks are rarely changed and never changed concurrently – Have time for major compaction
  • Data modelMarksByPhotoMarksByOwner (FreshFirst order)MarksUserIndex
  • Data modelMarksByPhotoKey Column Column ValuephotoId:String userId:byte[8] ownerUserId+mark+time : byte[20] – SUM(), AVG() on PhotoId=? – EXISTS ( PhotoId=?, UserId=?) 98% calls => “NOT EXISTS”- We want no disk reads here, Cap!- But cassandra need to read columns...
  • #1: Column Bloom Filter• How ?– Stores (Key, Column name) pairs in SSTable *-Filter.db• Pros– No disk access on NOT EXISTS– ... i.e. 98% of operations are memory only– Larger bloom filter => less false positives• Cons– Bloom filters became large - 100s of MBytes– .. lead to GC Promotion Failures (originally it was implemented as single long[])– fixed it (CASSANDRA-2466)
  • Profit!• New system– 8 cassandra nodes ( instead of 32 SQLs )– RF =2– Every row stored 2.5 times (in MarksByPhoto, ByOwner and UserIndex CFs)– ~ 10 TB of data– which is > 1TB per every single node• :-( still– A lot of data per node => no use for SSD– Major compaction yields 400 - 500 Gb SSTable files– .. which are unmanageable– .. lead to full disk cache invalidation as soon as compaction finishes– .. cannot be split across disks (RAID 10 is SLOWER)– .. but we need more spindles
  • #2: Split em !• How ?– Pre-partition every CF to 256 smaller CFs, based on key low byte e.g. MarksByPhoto_00, _01, _FF– Now every node has 32*RF(2)=64 smaller CFs of size 5-10 Gb each– Made memtable flush every 2Mb– Made 10 separate data volumes + RAID 10 for commit log device• Pros– Even load distribution across disks ( and fixed it to be plain RR )– Cheap spinning disks– No massive disk cache invalidation on major compaction– 2Mb flushes do not stress disks– More parallelization abilities (e.g. we reduced startup time from 30 min -> 3 )
  • #3: Uniform Replication 00 Thrift calls R1 192 64 R2 86 107 R3 128
  • #3: Uniform Replication RF=3 00 Thrift calls R1 192 64 R2 86Even worse for RF=2 107 R3 128
  • What happens ?• On node failure – Additional load on live node (THRIFT CPU, Hint storage) – 300+ clients want to establish 20-30 connections each in 1 second (and thrift is slow on this) – ... Clients decide secondary replica is dead as well – ... No availability on part of keys ;-(• Inconvenient – You need to watch max pool sizes are 2x as large as necessary – Ensure each node capacity is > 2x
  • Own replication• How it works ? See source code at github/odnoklassniki Look for RackAwareOdklEvenStrategy• What it does ? – All Keys of every single node are replicated across ALL nodes from other DCs (and not only on its ring neighbors)• Profit! – Every single node failure adds a tiny fraction of load to others
  • That’s iton photo marks Oleg Anastasyev oa@odnoklassniki.ru odnoklassniki.ru/oa github.com/odnoklassniki/apache-cassandra cassandra.apache.org
  • Some problems left application servers PhotoMarksDAOImpl THRIFT +hector application servers cassandra cluster application servers• THRIFT is slow, esp on connect even newest one from cassandra 1.1 is slower on communication and ser/deser than our BLOS; employs funny IDL (see slideshare.net/m0nstermind/java-13078132)• DTO <->THRIFT <-> CS translation• Multiple roundtrips per transaction
  • Meet odnoklassniki-like application servers PhotoMarksDAOImpl application servers LikeS BLOS +hector application servers cassandra cluster application servers• All BL is co-located on CS JVM => much less net roundtrips; less partial failure probability; DTO <-> CS direct translation• App specialized caches => faster, less RAM, store DTO, own policy• CF Data listeners => custom replicas merge logic• Row processors => (custom) bulk data processing• Direct Access to in memory bloom filters => fast friends like it too
  • That’s it !Thank you ! Oleg Anastasyev oa@odnoklassniki.ru odnoklassniki.ru/oa github.com/odnoklassniki/apache-cassandra cassandra.apache.org
  • #3: Parallel readClient 00 Slow Data slow result, timeouts Hash 192 64 Wrong Hash Background Read Repair 128
  • #3: Parallel read Slow ? FGC ? Overloaded ?Client 00 Slow Data slow result, timeouts Hash 192 64 Wrong Hash Background Read Repair 128
  • #3: Parallel readParallelReadResolver:1. asks all replicas for data 002. waits for # of responds CL requires3. resolves and returns to client4. waits for the rest in consistency thread Slow Data Data 192 64Pros:• Unnoticed single node problems Wrong Data• Response time stabilityCons:• More traffic Background (negligible for small data) Read Repair 128
  • Cassandra : replicationReplicationStrategy: 00Token => InetAddress 22• Simple• RackAware 43 R1 192 64 86 R2 107 128 R3
  • Data modelMarksByPhotoMarksByOwner (FreshFirst order)MarksUserIndex
  • Data modelMarksByOwner (FreshFirst order)Key Column name Column ValueownerId:String time+photoId+userId : byte[24] mark : byte[4] time+photoId+userId : byte[24] mark : byte[4] ... ... – OwnerId=? ORDER BY Timestamp DESC -- who marked my photos ? – COUNT(*) OwnerId=? AND Timestamp>? -- how many new marks are ?
  • Data modelMarksUserIndexKey Column Column ValueuserId:String photoId:byte[8] “” : byte[0] photoId:byte[8] “” : byte[0] ... ... – UserId=? --for cleanup
  • Other extensions• Node local Maintenance Manager• Commit log archive• Data snapshot backup• Local CF storages