बाजार डेटा की 7.3 बिलियन पंक्तियों को कैसे स्टोर किया जाए (पढ़ने के लिए अनुकूलित)?

Question 1

मेरे पास 1998 के बाद से 1000 शेयरों के 1 मिनट के डेटा की कुल संख्या है, जो कुल (2012-1998)*(365*24*60)*1000 = 7.3 Billionपंक्तियों के आसपास है ।

अधिकांश (99.9%) उस समय जब मैं केवल पढ़ने के अनुरोध करूंगा ।

Db में इस डेटा को स्टोर करने का सबसे अच्छा तरीका क्या है?

7.3 बी पंक्तियों के साथ 1 बड़ी तालिका?
7.3M पंक्तियों के साथ 1000 टेबल (प्रत्येक स्टॉक प्रतीक के लिए एक)?
डेटाबेस इंजन की कोई सिफारिश? (मैं अमेज़न RDS 'MySQL का उपयोग करने की योजना बना रहा हूं)

मैं डेटासेट से निपटने के लिए उपयोग नहीं कर रहा हूँ, इसलिए यह मेरे लिए सीखने का एक शानदार अवसर है। मैं आपकी मदद और सलाह की बहुत सराहना करूंगा।

संपादित करें:

यह एक नमूना पंक्ति है:

'XX', 20041208, 938, 43.7444, 43.7541, 43.735, 43.7444, 35116.7, 1, 0, 0

कॉलम 1 स्टॉक सिंबल है, कॉलम 2 तारीख है, कॉलम 3 मिनट है, बाकी खुले-उच्च-कम-करीब मूल्य, वॉल्यूम और 3 पूर्णांक कॉलम हैं।

अधिकांश प्रश्न ऐसे होंगे जैसे "मुझे 12 अप्रैल 2012 12:15 और 13 अप्रैल 2012 12:52 के बीच AAPL की कीमतें दें।"

हार्डवेयर के बारे में: मैं अमेज़ॅन आरडीएस का उपयोग करने की योजना बना रहा हूं इसलिए मैं उस पर लचीला हूं

Question 2

हमें प्रश्नों, और आपके हार्डवेयर वातावरण के बारे में बताएं।

जब तक आप समानता का लाभ उठा सकते हैं, मैं Hadoop या कुछ समान का उपयोग करके NoSQL जाने के लिए बहुत लुभाया जा सकता है ।

अपडेट करें

ठीक है, क्यों?

सबसे पहले, ध्यान दें कि मैंने प्रश्नों के बारे में पूछा। आप नहीं कर सकते हैं - और हम निश्चित रूप से नहीं कर सकते हैं - इन सवालों का जवाब बिना यह जाने कि कार्यभार कैसा है। (मैं सह-संयोग से इस बारे में एक लेख जल्द ही प्रदर्शित करूंगा, लेकिन मैं आज इसे लिंक नहीं कर सकता।) लेकिन समस्या का पैमाना मुझे एक बिग ओल्ड डेटाबेस से दूर जाने के बारे में सोचने की वजह बनाता है।

समान प्रणालियों के साथ मेरा अनुभव बताता है कि पहुंच या तो बड़ा अनुक्रमिक होगा (किसी प्रकार की समय श्रृंखला विश्लेषण की गणना करना) या बहुत ही लचीली डेटा खनन (ओएलईडी)। अनुक्रमिक डेटा को बेहतर और तेजी से क्रमिक रूप से नियंत्रित किया जा सकता है; OLAP का अर्थ है बहुत सारे और बहुत सारे सूचकांकों की गणना करना, जो या तो बहुत समय लेंगे या बहुत सारे स्थान लेंगे।
यदि आप ऐसा कर रहे हैं जो एक OLAP दुनिया में कई डेटा के खिलाफ प्रभावी रूप से बड़े रन हैं, हालांकि, स्तंभ-उन्मुख दृष्टिकोण सबसे अच्छा हो सकता है।
यदि आप यादृच्छिक प्रश्न करना चाहते हैं, विशेष रूप से क्रॉस-तुलना करना, एक Hadoop सिस्टम प्रभावी हो सकता है। क्यों? चूंकि
- आप अपेक्षाकृत कमोडिटी हार्डवेयर पर समानता का बेहतर उपयोग कर सकते हैं।
- आप उच्च विश्वसनीयता और अतिरेक को बेहतर ढंग से लागू कर सकते हैं
- उन समस्याओं में से कई खुद को स्वाभाविक रूप से MapReduce प्रतिमान के लिए उधार देते हैं।

लेकिन तथ्य यह है कि जब तक हम आपके कार्यभार के बारे में जानते हैं, तब तक कुछ भी निश्चित रूप से कहना असंभव है।

Question 3

इसलिए डेटाबेस उन स्थितियों के लिए हैं जहां आपके पास एक बड़ा जटिल स्कीमा है जो लगातार बदल रहा है। आपके पास केवल एक "टेबल" है, जो साधारण संख्यात्मक क्षेत्रों से भरा हुआ है। मैं इसे इस तरह से करूंगा:

रिकॉर्ड प्रारूप रखने के लिए C / C ++ संरचना तैयार करें:

struct StockPrice
{
    char ticker_code[2];
    double stock_price;
    timespec when;
    etc
};

फिर आकार की गणना करें (स्टॉकप्राइस [एन]) जहां एन रिकॉर्ड की संख्या है। (64-बिट सिस्टम पर) यह केवल कुछ सौ गिग होना चाहिए, और $ 50 HDD पर फिट होना चाहिए।

फिर एक फ़ाइल को उस आकार और mmap (linux पर, या विंडोज़ पर CreateFileMapping का उपयोग करें) में काट दें:

//pseduo-code
file = open("my.data", WRITE_ONLY);
truncate(file, sizeof(StockPrice[N]));
void* p = mmap(file, WRITE_ONLY);

Mmaped पॉइंटर को StockPrice * पर कास्ट करें, और अपने डेटा को पास से भरते हुए पास बनाएं। मिमीप को बंद करें, और अब आपके पास एक फ़ाइल में एक बड़ा बाइनरी एरे में आपका डेटा होगा जिसे बाद में फिर से मिमीपेड किया जा सकता है।

StockPrice* stocks = (StockPrice*) p;
for (size_t i = 0; i < N; i++)
{
    stocks[i] = ParseNextStock(stock_indata_file);
}
close(file);

अब आप इसे फिर से केवल किसी भी प्रोग्राम से पढ़ सकते हैं और आपका डेटा आसानी से उपलब्ध होगा:

file = open("my.data", READ_ONLY);
StockPrice* stocks = (StockPrice*) mmap(file, READ_ONLY);

// do stuff with stocks;

तो अब आप इसे सिर्फ इन-मेमोरी अरैम्प्स की तरह ट्रीट कर सकते हैं। आप अपने "प्रश्नों" के आधार पर विभिन्न प्रकार के सूचकांक डेटा संरचनाएं बना सकते हैं। कर्नेल पारदर्शी रूप से / से डेटा को स्वैप करने के साथ निपटेगा ताकि यह पूरी तरह से तेज़ हो।

यदि आप एक निश्चित पहुंच पैटर्न (उदाहरण के लिए सन्निहित तिथि) की उम्मीद करते हैं, तो उस क्रम में सरणी को क्रमबद्ध करना सबसे अच्छा है, इसलिए यह डिस्क को क्रमिक रूप से हिट करेगा।

Question 4

मेरे पास 1000 स्टॉक के 1 मिनट के डेटा का डेटा है [...] सबसे (99.9%) उस समय जब मैं केवल पढ़ने के लिए अनुरोध करूंगा ।

एक बार भंडारण करना और कई बार समय-आधारित संख्यात्मक डेटा पढ़ना एक उपयोग मामला है जिसे "समय श्रृंखला" कहा जाता है। अन्य सामान्य समय श्रृंखला इंटरनेट ऑफ़ थिंग्स, सर्वर मॉनिटरिंग सांख्यिकी, एप्लिकेशन ईवेंट आदि में सेंसर डेटा हैं।

यह सवाल 2012 में पूछा गया था, और तब से, कई डेटाबेस इंजन विशेष रूप से समय श्रृंखला के प्रबंधन के लिए सुविधाओं का विकास कर रहे हैं। मैं InfluxDB के साथ बहुत अच्छे परिणाम है , जो खुला खट्टा है , गो में लिखा है, और MIT- लाइसेंस प्राप्त है।

InfluxDB को विशेष रूप से स्टोर श्रृंखला डेटा को क्वेरी और स्टोर करने के लिए अनुकूलित किया गया है। कैसेंड्रा की तुलना में बहुत अधिक है , जिसे अक्सर समय श्रृंखला के भंडारण के लिए महान माना जाता है:

टाइम सीरीज़ के लिए ऑप्टिमाइज़िंग में कुछ ट्रेडऑफ़ शामिल थे। उदाहरण के लिए:

मौजूदा डेटा के अपडेट एक दुर्लभ घटना है और विवादास्पद अपडेट कभी नहीं होते हैं। समय श्रृंखला डेटा मुख्य रूप से नया डेटा है जो कभी अपडेट नहीं किया जाता है।

प्रो: अद्यतनों तक पहुंच सीमित करने से बढ़ी हुई क्वेरी और प्रदर्शन लिखने की अनुमति मिलती है

Con: अद्यतन कार्यक्षमता काफी प्रतिबंधित है

में खुले sourced मानक ,

84x कम डिस्क स्थान का उपयोग करते हुए और क्वेरी गति में आने पर अपेक्षाकृत समान प्रदर्शन प्रदान करते हुए 27x के साथ सभी तीन परीक्षणों में इन्फ्लक्सबैंक ने मोंगोबीडी को बेहतर प्रदर्शन दिया।

प्रश्न भी बहुत सरल हैं। यदि आपकी पंक्तियाँ दिखती हैं <symbol, timestamp, open, high, low, close, volume>, तो InfluxDB के साथ आप बस इसे स्टोर कर सकते हैं, फिर आसानी से क्वेरी कर सकते हैं। पिछले 10 मिनट के आंकड़ों के लिए कहें:

SELECT open, close FROM market_data WHERE symbol = 'AAPL' AND time > '2012-04-12 12:15' AND time < '2012-04-13 12:52'

कोई आईडी नहीं है, कोई चाबी नहीं है, और कोई भी जुड़ने के लिए नहीं है। आप बहुत सारे दिलचस्प एकत्रीकरण कर सकते हैं । आपको पोस्टग्रेसीक्यूएल के साथ तालिका को लंबवत रूप से विभाजित करने की आवश्यकता नहीं है , या अपने स्कीमा को सेकंड के सरणियों में मोंटबीडीबी के साथ जोड़ दें । इसके अलावा, InfluxDB वास्तव में अच्छी तरह से संपीड़ित करता है, जबकि PostgreSQL आपके पास डेटा के प्रकार पर कोई संपीड़न करने में सक्षम नहीं होगा ।

Question 5

ठीक है, इसलिए यह अन्य उत्तरों से कुछ हद तक दूर है, लेकिन ... मुझे यह महसूस होता है कि यदि आपके पास एक निश्चित रिकॉर्ड आकार के साथ फाइल सिस्टम (एक स्टॉक प्रति फ़ाइल, शायद) में डेटा है, तो आप डेटा प्राप्त कर सकते हैं वास्तव में आसानी से: एक विशेष स्टॉक और समय सीमा के लिए एक क्वेरी दी गई, आप सही जगह की तलाश कर सकते हैं, आपको आवश्यक सभी डेटा प्राप्त होंगे (आपको ठीक-ठीक पता होगा कि कितने बाइट्स हैं), डेटा को आपके द्वारा आवश्यक प्रारूप में रूपांतरित करें (जो आप कर सकते थे) आपके भंडारण प्रारूप के आधार पर बहुत जल्दी) और आप दूर हैं।

मुझे अमेज़ॅन स्टोरेज के बारे में कुछ भी नहीं पता है, लेकिन अगर आपके पास डायरेक्ट फाइल एक्सेस जैसी कोई चीज़ नहीं है, तो आप मूल रूप से ब्लब कर सकते हैं - आपको बड़े ब्लब्स (कम रिकॉर्ड) को संतुलित करने की आवश्यकता होगी, लेकिन संभवतः प्रत्येक की आवश्यकता से अधिक डेटा पढ़ना समय) छोटे ब्लब्स के साथ (अधिक रिकॉर्ड जो अधिक उपरि दे रहा है और संभवतः उन पर प्राप्त करने के लिए अधिक अनुरोध करता है, लेकिन हर बार कम बेकार डेटा वापस आ जाता है)।

आगे आप कैशिंग जोड़ते हैं - मैं उदाहरण के लिए विभिन्न सर्वरों को संभालने के लिए अलग-अलग स्टॉक देने का सुझाव दूंगा - और आप बहुत अधिक मेमोरी से सेवा कर सकते हैं। यदि आप पर्याप्त सर्वर पर पर्याप्त मेमोरी खर्च कर सकते हैं, तो "लोड ऑन डिमांड" भाग को बायपास करें और स्टार्ट-अप पर सभी फाइलों को लोड करें। यह धीमी गति से स्टार्ट-अप की लागत पर (जो स्पष्ट रूप से विफलता को प्रभावित करता है, जब तक कि आप किसी विशेष स्टॉक के लिए हमेशा दो सर्वरों को बर्दाश्त नहीं कर सकते , जो सहायक होगा)।

ध्यान दें कि आपको प्रत्येक रिकॉर्ड के लिए स्टॉक प्रतीक, दिनांक या मिनट को संग्रहीत करने की आवश्यकता नहीं है - क्योंकि वे उस फ़ाइल में अंतर्निहित हैं जो आप लोड कर रहे हैं और फ़ाइल के भीतर की स्थिति। आपको यह भी विचार करना चाहिए कि आपको प्रत्येक मूल्य के लिए क्या सटीकता की आवश्यकता है, और उस कुशलता से कैसे स्टोर करें - आपने अपने प्रश्न में 6SF दिया है, जिसे आप 20 बिट्स में स्टोर कर सकते हैं। संभावित रूप से तीन 20-बिट पूर्णांकों को 64 बिट्स स्टोरेज में संग्रहीत करें: इसे एक long(या जो भी आपके 64-बिट पूर्णांक मान होगा) के रूप में पढ़ें और इसे तीन पूर्णांकों में वापस लाने के लिए मास्किंग / शिफ्टिंग का उपयोग करें। आपको यह जानने की आवश्यकता होगी कि किस पैमाने का उपयोग करना है, निश्चित रूप से - जिसे आप शायद अतिरिक्त 4 बिट्स में सांकेतिक शब्दों में बदलना कर सकते हैं, यदि आप इसे निरंतर नहीं बना सकते हैं।

आपने यह नहीं कहा है कि अन्य तीन पूर्णांक कॉलम क्या हैं, लेकिन यदि आप उन तीनों के लिए 64 बिट्स के साथ भाग सकते हैं, तो आप 16 बाइट्स में एक संपूर्ण रिकॉर्ड संग्रहीत कर सकते हैं। पूरे डेटाबेस के लिए यह केवल ~ 110GB है, जो वास्तव में बहुत ज्यादा नहीं है ...

संपादित करें: विचार करने के लिए दूसरी बात यह है कि संभवतः स्टॉक सप्ताहांत में नहीं बदलता है - या वास्तव में रात भर। यदि शेयर बाजार केवल 8 घंटे प्रति दिन, सप्ताह में 5 दिन खुला रहता है, तो आपको 168 के बजाय प्रति सप्ताह केवल 40 मान चाहिए। उस समय आप अपनी फ़ाइलों में केवल 28GB डेटा के साथ समाप्त हो सकते हैं ... जो लगता है आप से बहुत छोटा शायद मूल रूप से सोच रहे थे। मेमोरी में इतना डेटा होना बहुत ही उचित है।

संपादित करें: मुझे लगता है कि मुझे इस स्पष्टीकरण से चूक हो गई है कि यह दृष्टिकोण यहां क्यों फिट है: आपको अपने डेटा के एक बड़े हिस्से के लिए एक बहुत ही अनुमानित पहलू मिला है - स्टॉक टिकर, दिनांक और समय। टिकर को एक बार (फाइलनाम के रूप में) व्यक्त करके और डेटा की स्थिति में पूरी तरह से निहित तारीख / समय को छोड़कर , आप काम का एक पूरा गुच्छा निकाल रहे हैं। यह String[]एक Map<Integer, String>- और के बीच के अंतर की तरह एक सा है - यह जानते हुए कि आपका सरणी सूचकांक हमेशा 0 से शुरू होता है और सरणी की लंबाई तक 1 की वृद्धि में ऊपर जाता है जो त्वरित पहुंच और अधिक कुशल भंडारण की अनुमति देता है।

Question 6

यह मेरी समझ है कि एचडीएफ 5 को विशेष रूप से स्टॉक डेटा के समय-श्रृंखला भंडारण के साथ एक संभावित अनुप्रयोग के रूप में डिज़ाइन किया गया था। फैलो स्टैकर्स ने प्रदर्शित किया है कि एचडीएफ 5 बड़ी मात्रा में डेटा के लिए अच्छा है: गुणसूत्र , भौतिकी ।

Question 7

यहां Microsoft SQL Server 2012 डेटाबेस के शीर्ष पर एक मार्केट डेटा सर्वर बनाने का प्रयास किया गया है, जो ओएलएपी विश्लेषण के लिए अच्छा होना चाहिए, एक मुक्त ओपन प्रोजेक्ट प्रोजेक्ट:

http://github.com/kriasoft/market-data

Question 8

सबसे पहले, वर्ष में 365 व्यापारिक दिन नहीं होते हैं, छुट्टियों के साथ 52 सप्ताहांत (104) = कहते हैं कि 250 x दिन के बाजार के वास्तविक घंटे खुलते हैं जैसे किसी ने कहा था, और प्रतीक का उपयोग करने के लिए प्राथमिक कुंजी एक अच्छा विचार नहीं है। चूंकि प्रतीकों में परिवर्तन होता है, इसलिए प्रतीक (char) के साथ k_equity_id (सांख्यिक) का उपयोग करें क्योंकि प्रतीक इस प्रकार हो सकते हैं, या GAC-DB-B.TO, तो मूल्य जानकारी के डेटा तालिकाओं में, आपके पास, इसलिए आपके 7.3 का अनुमान है। 14 वर्षों से प्रति प्रतीक लगभग 1.7 मिलियन पंक्तियों के बाद ही अरबों की गणना की जाती है।

k_equity_id k_date k_minute

और ईओडी तालिका के लिए (जो अन्य डेटा पर 1000x देखी जाएगी)

k_equity_id k_date

दूसरा, एक ही डीबी टेबल में और ईओडी टेबल (दिन के अंत) के रूप में एक ही डीबी टेबल में अपने ओएचएलसी को मिनट डेटा से स्टोर न करें, क्योंकि कोई भी व्यक्ति पीएनएफ, या लाइन चार्ट को एक वर्ष की अवधि में देखना चाहता है, जिसमें शून्य ब्याज है मिनट की जानकारी।

Question 9

मुझे सलाह देते हैं कि आप अपाचे सोल पर एक नज़र डालें , जो मुझे लगता है कि आपकी विशेष समस्या के लिए आदर्श होगा। मूल रूप से, आप पहले अपने डेटा (प्रत्येक पंक्ति में "दस्तावेज़") को अनुक्रमित करेंगे। सोलर को खोज के लिए अनुकूलित किया गया है और तिथियों पर देशी प्रश्नों का समर्थन करता है। आपकी नाममात्र की क्वेरी,

"Give me the prices of AAPL between April 12 2012 12:15 and April 13 2012 12:52"

अनुवाद कुछ इस तरह होगा:

?q=stock:AAPL AND date:[2012-04-12T12:15:00Z TO 2012-04-13T12:52:00Z]

"स्टॉक" मान लें कि स्टॉक का नाम है और "दिनांक" एक "डेटफिल्ड" है जिसे इंडेक्सिंग पर आपके इनपुट डेटा के "दिनांक" और "मिनट" कॉलम से बनाया गया है। सोलर अविश्वसनीय रूप से लचीला है और मैं वास्तव में इसके बारे में पर्याप्त अच्छी बातें नहीं कह सकता। इसलिए, उदाहरण के लिए, यदि आपको मूल डेटा में फ़ील्ड बनाए रखने की आवश्यकता है, तो आप शायद क्वेरी (या फ़िल्टर) के हिस्से के रूप में "DateField" को गतिशील रूप से बनाने का एक तरीका पा सकते हैं।

Question 10

मुझे लगता है कि कोई भी प्रमुख आरडीबीएमएस इसे संभाल लेगा। परमाणु स्तर पर, सही विभाजन वाली एक तालिका उचित लगती है (यदि आपके डेटा उपयोग के आधार पर विभाजन तय हो - तो यह प्रतीक या तिथि के समान है)।

आप परमाणु स्तर के ऊपर तेजी से पहुंच के लिए कुल तालिकाओं के निर्माण में भी देख सकते हैं। उदाहरण के लिए यदि आपका डेटा दिन में है, लेकिन आपको अक्सर वीकेक या महीने के स्तर पर डेटा वापस मिल जाता है, तो यह एक समग्र तालिका में पूर्व-गणना की जा सकती है। कुछ डेटाबेस में यह कैश्ड दृश्य (विभिन्न डीबी समाधानों के लिए विभिन्न नाम - लेकिन मूल रूप से परमाणु डेटा पर इसका एक दृश्य हो सकता है, लेकिन एक बार दृश्य को कैश / कड़ा किया गया निश्चित अस्थायी तालिका - जिसे बाद में मिलान किए गए प्रश्नों के लिए क्वेरी किया गया है) । यह मेमोरी / डिस्क स्थान को खाली करने के लिए अंतराल पर गिराया जा सकता है)।

मुझे लगता है कि डेटा उपयोग के रूप में हम आपको कुछ विचार के साथ और अधिक मदद कर सकते हैं।

Question 11

आपको स्मृति मॉडल में एक सरल अनुकूलित के साथ धीमे समाधान की तुलना करनी चाहिए। एक असंपीड़ित यह एक 256 जीबी रैम सर्वर में फिट बैठता है। एक स्नैपशॉट 32 K में फिट बैठता है और आप इसे केवल डेटाइम और स्टॉक पर अलग-अलग अनुक्रमित करते हैं। फिर आप विशेष स्नैपशॉट बना सकते हैं, क्योंकि एक का खुला होना अक्सर पिछले के बराबर होता है।

[संपादित करें] आपको क्यों लगता है कि डेटाबेस (rdbms या nosql) का उपयोग करना समझ में आता है? यह डेटा नहीं बदलता है, और यह स्मृति में फिट बैठता है। यह एक उपयोग मामला नहीं है जहां एक dbms मान जोड़ सकता है।

Question 12

यदि आपके पास हार्डवेयर है, तो मैं MySQL क्लस्टर की सलाह देता हूं । आपको MySQL / RDBMS इंटरफ़ेस मिलता है जिससे आप परिचित हैं, और आपको तेज़ और समानांतर लेखन मिलता है। नेटवर्क विलंबता के कारण नियमित MySQL की तुलना में रीड्स धीमा हो जाएगा, लेकिन आपके पास MySQL क्लस्टर और NDB स्टोरेज इंजन के काम करने के तरीके के कारण प्रश्नों और रीडर्स को समानांतर करने में सक्षम होने का लाभ है।

सुनिश्चित करें कि आपके पास पर्याप्त MySQL क्लस्टर मशीन और उनमें से प्रत्येक के लिए पर्याप्त मेमोरी / RAM है - MySQL क्लस्टर एक भारी मेमोरी-उन्मुख डेटाबेस आर्किटेक्चर है।

या रेडिस , यदि आपको अपने रीड / राइट्स के लिए कोई महत्वपूर्ण-मूल्य / NoSQL इंटरफ़ेस नहीं मिलता है। सुनिश्चित करें कि रेडिस के पास पर्याप्त मेमोरी है - इसके सुपर फास्ट फॉर रीड एंड राइट्स, आप इसके साथ बुनियादी प्रश्न कर सकते हैं (गैर-आरडीबीएमएस हालांकि) लेकिन यह एक इन-मेमोरी डेटाबेस भी है।

जैसे दूसरों ने कहा है, आपके द्वारा चलाए जा रहे प्रश्नों के बारे में अधिक जानने से मदद मिलेगी।

Question 13

आप स्तंभ तालिका / डेटाबेस में संग्रहीत डेटा चाहते हैं । वर्टिका और ग्रीनप्लम जैसे डेटाबेस सिस्टम स्तंभ डेटाबेस हैं, और मेरा मानना है कि SQL सर्वर अब स्तंभ तालिकाओं के लिए अनुमति देता है। ये SELECTबहुत बड़े डेटासेट से आईएनजी के लिए बेहद कुशल हैं। वे बड़े डेटासेट आयात करने में भी कुशल हैं।

एक मुक्त स्तंभ डेटाबेस MonetDB है ।

Question 14

यदि आपका उपयोग मामला एकत्रीकरण के बिना सरल रीड पंक्तियों के लिए है, तो आप एयरोस्पाइक क्लस्टर का उपयोग कर सकते हैं। यह मेमोरी डेटाबेस में दृढ़ता के लिए फाइल सिस्टम के समर्थन के साथ है। यह भी SSD अनुकूलित है।

यदि आपके उपयोग के मामले में समग्र डेटा की जरूरत है, तो दिनांक सीमा निर्धारण के साथ Mongo DB क्लस्टर के लिए जाएं। आप शार्क में साल भर के डेटा को क्लब कर सकते हैं।