कैसंड्रा को बेहतर बनाने के तरीके मेरे परिदृश्य में प्रदर्शन

Question

हमने हाल ही में उत्पादन में कैसंड्रा डेटाबेस का उपयोग करना शुरू कर दिया है। हमारे पास single cross colo cluster of 24 nodes है जिसका अर्थ 12 nodes in PHX और 12 nodes in SLC colo है। हमारे पास replication factor of 4 है जिसका अर्थ है 2 copies will be there in each datacenter।

नीचे जिस तरह से keyspace और column families हमारे Production DBA's द्वारा बनाए गए हैं।

placement_strategy = 'org.apache.cassandra.locator.NetworkTopologyStrategy' के साथ keyspace प्रोफ़ाइल बनाने और strategy_options = {एसएलसी: 2, PHX: 2};

create column family PROFILE_USER 
with key_validation_class = 'UTF8Type' 
and comparator = 'UTF8Type' 
and default_validation_class = 'UTF8Type' 
and gc_grace = 86400; 

हम Cassandra 1.2.2 चल रहे हैं और यह org.apache.cassandra.dht.Murmur3Partitioner है, KeyCaching, SizeTieredCompactionStrategy और Virtual Nodes को भी सक्षम है। nodes-

16 cores, 32 threads 
128GB RAM 
4 x 600GB SAS in Raid 10, 1.1TB usable 
2 x 10GbaseT NIC, one usable 

नीचे कैसेंड्रा उत्पादन के लिए

मशीन निर्दिष्टीकरण परिणाम मैं हो रही है।

Read Latency(95th Percentile)  Number of Threads Duration the program was running(in minutes) Throughput(requests/seconds) Total number of id's requested Total number of columns requested 
    9 milliseconds       10      30            1977        3558701      65815867 

मुझे यकीन है कि क्या अन्य बातों के मैं काफी बेहतर read performance पाने के लिए कैसेंड्रा के साथ बाहर यह कोशिश करनी चाहिए नहीं कर रहा हूँ। मुझे लगता है कि यह मेरे मामले में डिस्क मार रहा है। क्या मुझे कुछ उच्च संख्या में प्रतिकृति फैक्टर को बढ़ाने की कोशिश करनी चाहिए? कोई अन्य सुझाव?

मुझे लगता है कि एसएसडी की तुलना में एचडीडी से डेटा पढ़ने के बारे में 6-12ms है? मेरे मामले में यह हर बार डिस्क को मार रहा है और मुझे लगता है कि कुंजी कैश सक्षम करना ठीक काम नहीं कर रहा है। मैं पंक्ति कैश को सक्षम नहीं कर सकता क्योंकि यह ओएस पेज कैश का उपयोग करने के लिए अधिक कुशल है। JVM में पंक्ति कैश को बनाए रखना बहुत महंगा है, इस प्रकार पंक्तियों की छोटी संख्या के लिए पंक्ति कैश की सिफारिश की जाती है, जैसे < केवल 100K पंक्तियां।

क्या कोई तरीका है कि मैं यह सत्यापित कर सकता हूं कि मेरे मामले में कीकैचिंग ठीक काम कर रही है या नहीं?

यह जब मैं स्तंभ परिवार

create column PROFILE 
    with column_type = 'Standard' 
    and comparator = 'UTF8Type' 
    and default_validation_class = 'UTF8Type' 
    and key_validation_class = 'UTF8Type' 
    and read_repair_chance = 0.1 
    and dclocal_read_repair_chance = 0.0 
    and populate_io_cache_on_flush = false 
    and gc_grace = 86400 
    and min_compaction_threshold = 4 
    and max_compaction_threshold = 32 
    and replicate_on_write = true 
    and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' 
    and caching = 'KEYS_ONLY' 
    and compression_options = {'sstable_compression' : 'org.apache.cassandra.io.compress.SnappyCompressor'}; 

के लिए स्कीमा दिखाते हैं कि मैं क्या मिलता है क्या मैं एक परिवर्तन करना चाहिए अच्छा पढ़ा प्रदर्शन प्राप्त करने के है है?

Answer 1

मुझे लगता है कि यह मेरे मामले में डिस्क को मार रहा है। क्या मुझे कुछ उच्च संख्या में प्रतिकृति फैक्टर को बढ़ाने की कोशिश करनी चाहिए? कोई अन्य सुझाव?

यदि आपका डेटा स्मृति से बहुत बड़ा है और आपकी पहुंच यादृच्छिक के करीब है तो आप डिस्क को मार देंगे। यह ~ 10ms की लेटेंसी के साथ संगत है।

प्रतिकृति कारक बढ़ाने से मदद मिल सकती है, हालांकि यह आपके कैश को कम कुशल बना देगा क्योंकि प्रत्येक नोड अधिक डेटा स्टोर करेगा। यह शायद केवल तभी लायक है जब आपका पठन पैटर्न अधिकतर यादृच्छिक है, आपका डेटा बहुत बड़ा है, आपके पास कम स्थिरता आवश्यकताएं हैं और आपकी पहुंच भारी पढ़ी जाती है।

यदि आप पढ़ा विलंबता कम करना चाहते हैं, तो आप निम्न स्थिरता स्तर का उपयोग कर सकते हैं। स्थिरता स्तर सीएल पर पढ़ना।एक आम तौर पर स्थिरता की लागत पर सबसे कम पढ़ने विलंबता देता है। यदि CLLALL पर लिखते हैं तो आपको केवल CL.ONE पर लगातार पढ़ा जाएगा। लेकिन अगर स्थिरता की आवश्यकता नहीं है तो यह एक अच्छा व्यापार है।

यदि आप पढ़ने के माध्यम से पढ़ना चाहते हैं, तो आप read_repair_chance को कम कर सकते हैं। यह संख्या संभावना को निर्दिष्ट करती है कि कैसंद्रा प्रत्येक पढ़ने पर एक पढ़ने की मरम्मत करता है। मरम्मत पढ़ें उपलब्ध प्रतिकृतियों से पढ़ने और पुराने मूल्यों को अद्यतन करने में शामिल है।

यदि कम स्थिरता स्तर पर पढ़ना है, तो मरम्मत पढ़ें अतिरिक्त पढ़ने I/O को थ्रूपुट कम करता है। यह विलंबता को प्रभावित नहीं करता है (कम स्थिरता स्तर के लिए) क्योंकि पढ़ने की मरम्मत अतुल्यकालिक रूप से की जाती है। दोबारा, यदि आपके आवेदन के लिए स्थिरता महत्वपूर्ण नहीं है, तो थ्रूपुट सुधारने के लिए read_repair_chance को शायद 0.01 तक घटाएं।

क्या कोई तरीका है कि मैं यह सत्यापित कर सकता हूं कि मेरे मामले में कीचिंग ठीक काम कर रही है या नहीं? 'Nodetool जानकारी' के उत्पादन में

देखो और यह होगा उत्पादन की तरह एक पंक्ति:

कुंजी कैश: आकार 96,468,768 (बाइट), क्षमता 96,468,992 (बाइट), 959,293 हिट, 31,637,294 अनुरोध, 0.051 हालिया हिट रेट, सेकंड्स में 14400 बचत अवधि

यह आपको कुंजी कैश हिट दर देता है, जो ऊपर दिए गए उदाहरण में काफी कम है।

Answer 2

पुरानी पोस्ट लेकिन किसी और को इसके कारण आता है।

• यहां तक ​​कि आरएफ का उपयोग न करें। आपके आरएफ 4 में 3 नोड्स के कोरम की आवश्यकता होती है, यह 5 के आरएफ से अलग नहीं है।
• आपकी कुंजी कैश शायद ठीक काम कर रही है, यह केवल कैसंड्रा को बताती है जहां डिस्क स्थित है। यह केवल खोज समय कम कर देता है।
• आपके पास रैम प्री 3.0 की एक बड़ी मात्रा है, संभव है कि आप इस सब का लाभ नहीं उठा रहे हैं। नए कैसंड्रा नोड्स पर जी 1 जीसी आज़माएं।
• पंक्ति कुंजी कैश, सुनिश्चित करें कि आपके विभाजन को आपके द्वारा एक्सेस करने का इरादा रखने के तरीके में आदेश दिया गया है। पूर्व: यदि आप केवल हालिया डेटा उठा रहे हैं, तो सुनिश्चित करें कि timestamp DESC के बजाय आप timestamp ASC द्वारा ऑर्डर करें क्योंकि यह विभाजन के स्टार्ट से कैश होगा।
• समांतरता और बाल्टी क्वेरी। अपने विभाजन के आकार का मूल्यांकन करने के लिए nodetool cfhistograms का उपयोग करें। फिर यदि वे 100 एमबी से अधिक हो तो विभाजन को छोटे हिस्सों में आज़माएं और तोड़ दें। यदि आपको स्कैन करने की आवश्यकता है तो यहां से आप अपने प्रश्नों को SELECT x FROM table WHERE id = X and bucket in (1,2,3) पर बदल सकते हैं। "बाल्टी में" हटाने और इसे 3 अलग-अलग प्रश्नों में ले जाने से महत्वपूर्ण प्रदर्शन प्राप्त किया जा सकता है। पूर्व चल रहा है: Select... WHERE id = X and bucket = 1, Select ... WHERE id = X and bucket = 2 और एप्लिकेशन परत पर एकत्रीकरण कर रहा है।