इकाई संग्रह में स्थानीय संग्रह और DbSet शामिल करें

मेरी भागीदारी के साथ एक वर्ष से थोड़ा अधिक, निम्नलिखित "संवाद" हुआ:

.Net ऐप : अरे एंटिटी फ्रेमवर्क, कृपया मुझे ढेर सारा डेटा दें!
इकाई ढाँचा : क्षमा करें, मैंने आपको नहीं समझा। क्या मतलब?
.Net ऐप : हां, मुझे सिर्फ 100k लेनदेन का एक संग्रह मिला है। और अब हमें वहां इंगित की जाने वाली प्रतिभूतियों की कीमतों की शुद्धता की जल्दी से जांच करने की आवश्यकता है।
इकाई ढांचा : आह, ठीक है, चलो कोशिश करते हैं ...
.Net ऐप : यहाँ कोड है:

var query = from p in context.Prices join t in transactions on new { p.Ticker, p.TradedOn, p.PriceSourceId } equals new { t.Ticker, t.TradedOn, t.PriceSourceId } select p; query.ToList(); 

इकाई ढांचा :

क्लासिक! मुझे लगता है कि बहुत से लोग इस स्थिति से परिचित हैं: जब मैं वास्तव में "खूबसूरती से" चाहता हूं और जल्दी से स्थानीय संग्रह और डीबीसेट के जोइन का उपयोग करके डेटाबेस में खोज करता हूं । आमतौर पर यह अनुभव निराशाजनक होता है।

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

परिचय

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

कार्य

मान लीजिए कि कीमतों के साथ एक डेटाबेस है और लेनदेन का एक संग्रह है जिसके लिए आपको कीमतों की शुद्धता की जांच करने की आवश्यकता है। और मान लें कि हमारे पास निम्नलिखित कोड है।

 var localData = GetDataFromApiOrUser(); var query = from p in context.Prices join s in context.Securities on p.SecurityId equals s.SecurityId join t in localData on new { s.Ticker, p.TradedOn, p.PriceSourceId } equals new { t.Ticker, t.TradedOn, t.PriceSourceId } select p; var result = query.ToList(); 

यह कोड एंटिटी फ्रेमवर्क 6 में बिल्कुल भी काम नहीं करता है। इकाई फ्रेमवर्क कोर में - यह काम करता है, लेकिन सब कुछ क्लाइंट की तरफ से किया जाएगा और इस मामले में जब डेटाबेस में लाखों रिकॉर्ड होंगे - यह एक विकल्प नहीं है।

जैसा कि मैंने कहा, मैं इसे प्राप्त करने के लिए विभिन्न तरीकों की कोशिश करूंगा। सरल से जटिल तक। अपने प्रयोगों के लिए, मैं निम्नलिखित भंडार से कोड का उपयोग करता हूं। कोड का उपयोग करके लिखा गया है: C # , .net Core , EF Core और PostgreSQL ।

मैंने कुछ मीट्रिक भी शूट किए: समय बिताया और स्मृति की खपत। अस्वीकरण: यदि परीक्षण 10 मिनट से अधिक समय तक किया गया था, तो मैंने इसे बाधित कर दिया (प्रतिबंध ऊपर से है)। टेस्ट मशीन इंटेल कोर i5, 8 जीबी रैम, एसएसडी।

विधि 1. Naive

आइए सरल शुरू करें और निम्नलिखित कोड का उपयोग करें:

 var result = new List<Price>(); using (var context = CreateContext()) { foreach (var testElement in TestData) { result.AddRange(context.Prices.Where( x => x.Security.Ticker == testElement.Ticker && x.TradedOn == testElement.TradedOn && x.PriceSourceId == testElement.PriceSourceId)); } } 

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

मेमोरी की खपत कम है। एक बड़े संग्रह में 1 मिनट का समय लगता है। एक शुरुआत के लिए, बुरा नहीं है, लेकिन मैं इसे तेजी से चाहता हूं।

विधि 2: Naive समानांतर

आइए समानता को जोड़ने की कोशिश करें। डेटाबेस को कई थ्रेड से एक्सेस करने का विचार है।

 var result = new ConcurrentBag<Price>(); var partitioner = Partitioner.Create(0, TestData.Count); Parallel.ForEach(partitioner, range => { var subList = TestData.Skip(range.Item1) .Take(range.Item2 - range.Item1) .ToList(); using (var context = CreateContext()) { foreach (var testElement in subList) { var query = context.Prices.Where( x => x.Security.Ticker == testElement.Ticker && x.TradedOn == testElement.TradedOn && x.PriceSourceId == testElement.PriceSourceId); foreach (var el in query) { result.Add(el); } } } }); 

परिणाम:

छोटे संग्रह के लिए, यह दृष्टिकोण पहली विधि की तुलना में भी धीमा है। और सबसे बड़े के लिए - 2 बार तेजी से। दिलचस्प है, मेरी मशीन पर 4 धागे उत्पन्न हुए थे, लेकिन इससे 4x त्वरण नहीं हुआ। इससे पता चलता है कि इस पद्धति में ओवरहेड महत्वपूर्ण है: क्लाइंट साइड और सर्वर साइड दोनों पर। मेमोरी की खपत में वृद्धि हुई है, लेकिन महत्वपूर्ण रूप से नहीं।

विधि 3: एकाधिक शामिल हैं

समय कुछ और कोशिश करने के लिए और एक क्वेरी के लिए कार्य को कम करने का प्रयास करें। इसे निम्नानुसार किया जा सकता है:

1. टिकर , प्राइससोर्सआई और डेट के 3 अनूठे संग्रह तैयार करें
2. अनुरोध चलाएँ और 3 युक्तियों का उपयोग करें
3. स्थानीय स्तर पर परिणाम देखें

 var result = new List<Price>(); using (var context = CreateContext()) { //   var tickers = TestData.Select(x => x.Ticker).Distinct().ToList(); var dates = TestData.Select(x => x.TradedOn).Distinct().ToList(); var ps = TestData.Select(x => x.PriceSourceId).Distinct().ToList(); //    3 Contains var data = context.Prices .Where(x => tickers.Contains(x.Security.Ticker) && dates.Contains(x.TradedOn) && ps.Contains(x.PriceSourceId)) .Select(x => new { Price = x, Ticker = x.Security.Ticker, }) .ToList(); var lookup = data.ToLookup(x => $"{x.Ticker}, {x.Price.TradedOn}, {x.Price.PriceSourceId}"); //  foreach (var el in TestData) { var key = $"{el.Ticker}, {el.TradedOn}, {el.PriceSourceId}"; result.AddRange(lookup[key].Select(x => x.Price)); } } 

यहां समस्या यह है कि निष्पादन का समय और लौटाए गए डेटा की मात्रा डेटा पर ही निर्भर है (दोनों क्वेरी और डेटाबेस में)। यही है, केवल आवश्यक डेटा का एक सेट वापस आ सकता है, और अतिरिक्त रिकॉर्ड वापस किया जा सकता है (यहां तक ​​कि 100 गुना अधिक)।

यह निम्नलिखित उदाहरण का उपयोग करके समझाया जा सकता है। मान लीजिए कि डेटा के साथ निम्नलिखित तालिका है:

यह भी मान लें कि मुझे Ticker1 के लिए TradedOn = 2018-01-01 और TradedOn = 2018-01-02 के साथ Ticker2 के लिए कीमतों की आवश्यकता है।

तब टिकर के लिए अद्वितीय मूल्य = ( टिकर 1 , टिकर 2)
और TradedOn = ( 2018-01-01 , 2018-01-02 ) के लिए अद्वितीय मूल्य

हालांकि, 4 रिकॉर्ड वापस कर दिए जाएंगे, क्योंकि वे वास्तव में इन संयोजनों के अनुरूप हैं। बुरी बात यह है कि जितने अधिक खेतों का उपयोग किया जाता है, परिणामस्वरूप अतिरिक्त रिकॉर्ड प्राप्त करने की संभावना अधिक होती है।

इस कारण से, इस विधि द्वारा प्राप्त डेटा अतिरिक्त रूप से ग्राहक की ओर से फ़िल्टर किया जाना चाहिए। और यही सबसे बड़ी कमी है।
मैट्रिक्स निम्नानुसार हैं:

मेमोरी की खपत पिछले सभी तरीकों से खराब है। पढ़ी गई लाइनों की संख्या अनुरोधित संख्या से कई गुना अधिक है। बड़े संग्रह के लिए परीक्षण बाधित हो गए क्योंकि वे 10 मिनट से अधिक समय तक चले। यह तरीका अच्छा नहीं है।

विधि 4. बिल्डर की भविष्यवाणी करें

चलो इसे दूसरी तरफ आज़माते हैं: अच्छा पुराना अभिव्यक्ति । उनका उपयोग करके, आप निम्न रूप में 1 बड़ी क्वेरी बना सकते हैं:

… (.. AND .. AND ..) OR (.. AND .. AND ..) OR (.. AND .. AND ..) …

यह आशा करता है कि 1 अनुरोध बनाने और 1 कॉल के लिए केवल आवश्यक डेटा प्राप्त करना संभव होगा। कोड:

 var result = new List<Price>(); using (var context = CreateContext()) { var baseQuery = from p in context.Prices join s in context.Securities on p.SecurityId equals s.SecurityId select new TestData() { Ticker = s.Ticker, TradedOn = p.TradedOn, PriceSourceId = p.PriceSourceId, PriceObject = p }; var tradedOnProperty = typeof(TestData).GetProperty("TradedOn"); var priceSourceIdProperty = typeof(TestData).GetProperty("PriceSourceId"); var tickerProperty = typeof(TestData).GetProperty("Ticker"); var paramExpression = Expression.Parameter(typeof(TestData)); Expression wholeClause = null; foreach (var td in TestData) { var elementClause = Expression.AndAlso( Expression.Equal( Expression.MakeMemberAccess( paramExpression, tradedOnProperty), Expression.Constant(td.TradedOn) ), Expression.AndAlso( Expression.Equal( Expression.MakeMemberAccess( paramExpression, priceSourceIdProperty), Expression.Constant(td.PriceSourceId) ), Expression.Equal( Expression.MakeMemberAccess( paramExpression, tickerProperty), Expression.Constant(td.Ticker)) )); if (wholeClause == null) wholeClause = elementClause; else wholeClause = Expression.OrElse(wholeClause, elementClause); } var query = baseQuery.Where( (Expression<Func<TestData, bool>>)Expression.Lambda( wholeClause, paramExpression)).Select(x => x.PriceObject); result.AddRange(query); } 

कोड पिछले तरीकों की तुलना में अधिक जटिल निकला। मैन्युअल रूप से निर्माण अभिव्यक्ति सबसे आसान और सबसे तेज़ ऑपरेशन नहीं है।

मेट्रिक्स:

पिछले पद्धति की तुलना में अस्थायी परिणाम और भी खराब थे। ऐसा लगता है कि निर्माण के दौरान ओवरहेड और जब पेड़ के माध्यम से चलना एक अनुरोध का उपयोग करने से प्राप्त लाभ से बहुत अधिक हो गया।

विधि 5: साझा डेटा तालिका साझा की गई

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

अब, आप की जरूरत है परिणाम प्राप्त करने के लिए:

1. लेन-देन शुरू करें
2. क्वेरी डेटा को एक नई तालिका में अपलोड करें
3. क्वेरी को स्वयं चलाएं (नई तालिका का उपयोग करके)
4. लेन-देन वापस करें (प्रश्नों के लिए डेटा तालिका साफ़ करने के लिए)

कोड इस तरह दिखता है:

 var result = new List<Price>(); using (var context = CreateContext()) { context.Database.BeginTransaction(); var reducedData = TestData.Select(x => new SharedQueryModel() { PriceSourceId = x.PriceSourceId, Ticker = x.Ticker, TradedOn = x.TradedOn }).ToList(); //      context.QueryDataShared.AddRange(reducedData); context.SaveChanges(); var query = from p in context.Prices join s in context.Securities on p.SecurityId equals s.SecurityId join t in context.QueryDataShared on new { s.Ticker, p.TradedOn, p.PriceSourceId } equals new { t.Ticker, t.TradedOn, t.PriceSourceId } select p; result.AddRange(query); context.Database.RollbackTransaction(); } 

पहली मीट्रिक:

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

• आपको एक विशिष्ट प्रकार के क्वेरी के लिए एक तालिका बनानी होगी
• लेन-देन का उपयोग करना आवश्यक है (और उन पर DBMS संसाधनों को बर्बाद करना)
• और बहुत विचार है कि आप कुछ लिखने की जरूरत है, जब आप की जरूरत है, अजीब लग रहा है। और पढ़ें प्रतिकृति पर, यह सिर्फ काम नहीं करेगा।
  और बाकी अधिक या कम काम करने वाला समाधान है जो पहले से ही उपयोग किया जा सकता है।

विधि 6. मेमोरीजॉइन एक्सटेंशन

अब आप पिछले दृष्टिकोण को बेहतर बनाने का प्रयास कर सकते हैं। विचार हैं:

• एक तालिका का उपयोग करने के बजाय जो एक प्रकार के क्वेरी के लिए विशिष्ट है, आप कुछ सामान्यीकृत विकल्प का उपयोग कर सकते हैं। अर्थात्, शेयर्ड_क्वेरी_डेटा जैसे नाम के साथ एक तालिका बनाएं , और इसमें कई गाइड फ़ील्ड, कई लॉन्ग , कई स्ट्रिंग आदि जोड़ें। सरल नाम लिए जा सकते हैं: Guid1 , Guid2 , String1 , Long1 , Date2 , आदि। फिर इस तालिका का उपयोग 95% क्वेरी प्रकारों के लिए किया जा सकता है। संपत्ति के नाम बाद में चुनिंदा परिप्रेक्ष्य का उपयोग करके "समायोजित" हो सकते हैं।
• आगे आपको share_query_data के लिए एक DbSet जोड़ना होगा ।
• लेकिन क्या होगा यदि, डेटाबेस में डेटा लिखने के बजाय, वैल्यू निर्माण का उपयोग करके मानों को पारित किया जाए? यही है, यह आवश्यक है कि अंतिम SQL क्वेरी में, share_query_data तक पहुंचने के बजाय , VALUES के लिए एक अपील होनी चाहिए। यह कैसे करना है?
  
  • एंटिटी फ्रेमवर्क कोर में - बस FromSql का उपयोग कर।
  • Entity Framework 6 में - आपको DbInterception का उपयोग करना होगा - अर्थात, निष्पादन से पहले VALUES निर्माण को जोड़कर उत्पन्न SQL को बदल दें। यह एक सीमा में परिणाम देगा: एक ही अनुरोध में, एक से अधिक वाल्व निर्माण नहीं। लेकिन यह काम करेगा!
• चूँकि हम डेटाबेस में लिखने नहीं जा रहे हैं, तो हमें पहले चरण में साझा किया गया share_query_data टेबल मिलता है, क्या इसकी बिल्कुल भी आवश्यकता नहीं है? उत्तर: हाँ, इसकी आवश्यकता नहीं है, लेकिन DbSet की अभी भी आवश्यकता है, क्योंकि एंटिटी फ्रेमवर्क को प्रश्नों के निर्माण के लिए डेटा स्कीम का पता होना चाहिए। यह पता चला है कि हमें कुछ सामान्यीकृत मॉडल के लिए DbSet की आवश्यकता है जो डेटाबेस में मौजूद नहीं है और इसका उपयोग केवल एंटिटी फ्रेमवर्क को प्रेरित करने के लिए किया जाता है, कि यह जानता है कि यह क्या कर रहा है।

मैं इस दृष्टिकोण को लागू करने और यहां तक ​​कि इसे NuGet पैकेज EntityFrameworkCore.MemoryJoin ( कोड भी उपलब्ध है) के रूप में डिजाइन करने में कामयाब रहा। इस तथ्य के बावजूद कि नाम में कोर शब्द शामिल है, एंटिटी फ्रेमवर्क 6 भी समर्थित है। मैंने इसे MemoryJoin कहा, लेकिन वास्तव में यह VALUES निर्माण में DBMS को स्थानीय डेटा भेजता है और इस पर सभी काम किए जाते हैं।

कोड निम्नानुसार है:

 var result = new List<Price>(); using (var context = CreateContext()) { // :    ,      var reducedData = TestData.Select(x => new { x.Ticker, x.TradedOn, x.PriceSourceId }).ToList(); //  IEnumerable<>   IQueryable<> var queryable = context.FromLocalList(reducedData); var query = from p in context.Prices join s in context.Securities on p.SecurityId equals s.SecurityId join t in queryable on new { s.Ticker, p.TradedOn, p.PriceSourceId } equals new { t.Ticker, t.TradedOn, t.PriceSourceId } select p; result.AddRange(query); } 

मेट्रिक्स:

यह मेरे द्वारा आजमाया गया सबसे अच्छा परिणाम है। कोड बहुत सरल और सीधा था, और उसी समय रीड रेप्लिका के लिए काम कर रहा था।

 SELECT "p"."PriceId", "p"."ClosePrice", "p"."OpenPrice", "p"."PriceSourceId", "p"."SecurityId", "p"."TradedOn", "t"."Ticker", "t"."TradedOn", "t"."PriceSourceId" FROM "Price" AS "p" INNER JOIN "Security" AS "s" ON "p"."SecurityId" = "s"."SecurityId" INNER JOIN ( SELECT "x"."string1" AS "Ticker", "x"."date1" AS "TradedOn", CAST("x"."long1" AS int4) AS "PriceSourceId" FROM ( SELECT * FROM ( VALUES (1, @__gen_q_p0, @__gen_q_p1, @__gen_q_p2), (2, @__gen_q_p3, @__gen_q_p4, @__gen_q_p5), (3, @__gen_q_p6, @__gen_q_p7, @__gen_q_p8) ) AS __gen_query_data__ (id, string1, date1, long1) ) AS "x" ) AS "t" ON (("s"."Ticker" = "t"."Ticker") AND ("p"."PriceSourceId" = "t"."PriceSourceId") 

सभी कार्य SQL सर्वर पर 1 क्वेरी में किया जाता है। और यह एक छोटा सा सुखद अंत है, जिसके बारे में मैंने शुरुआत में बात की थी। फिर भी, इस पद्धति के उपयोग के लिए समझ और निम्न चरणों की आवश्यकता है:

• आपको अपने संदर्भ में एक अतिरिक्त DbSet जोड़ने की आवश्यकता है (हालाँकि तालिका को छोड़ा जा सकता है )
• सामान्यीकृत मॉडल में, जो डिफ़ॉल्ट रूप से उपयोग किया जाता है, 3 प्रकार के गाइड , स्ट्रिंग , डबल , लॉन्ग , डेट , आदि घोषित किए जाते हैं। यह 95% अनुरोध प्रकारों के लिए पर्याप्त होना चाहिए। और यदि आप FromLocalList में 20 फ़ील्ड्स के साथ ऑब्जेक्ट्स का संग्रह पास करते हैं , तो एक एक्सेप्शन फेंक दिया जाएगा, यह कहते हुए कि ऑब्जेक्ट बहुत जटिल है। यह एक नरम प्रतिबंध है और इसे दरकिनार किया जा सकता है - आप अपने प्रकार की घोषणा कर सकते हैं और वहां कम से कम 100 फ़ील्ड जोड़ सकते हैं। हालांकि, अधिक क्षेत्र काम करने के लिए धीमी हैं।
• मेरे लेख में अधिक तकनीकी विवरण वर्णित हैं।

निष्कर्ष

इस लेख में, मैंने JOIN स्थानीय संग्रह और DbSet विषय पर अपने विचार प्रस्तुत किए। मुझे ऐसा लग रहा था कि VALUES का उपयोग करने से मेरा विकास समुदाय के लिए रूचिकर हो सकता है। कम से कम मैं इस तरह के दृष्टिकोण से नहीं मिला था जब मैंने खुद इस समस्या को हल किया था। व्यक्तिगत रूप से, इस पद्धति ने मुझे अपनी वर्तमान परियोजनाओं में कई प्रदर्शन समस्याओं को दूर करने में मदद की, शायद यह आपकी भी मदद करेगी।

कोई कहेगा कि मेमोरीजॉइन का उपयोग बहुत अधिक " संक्षिप्त " है और इसे और विकसित करने की आवश्यकता है, और तब तक आपको इसका उपयोग करने की आवश्यकता नहीं है। यही कारण है कि मुझे बहुत संदेह था और लगभग एक साल तक मैंने यह लेख नहीं लिखा। मैं सहमत हूं कि मैं इसे आसान काम करना पसंद करूंगा (मुझे उम्मीद है कि यह एक दिन होगा), लेकिन मैं यह भी कहता हूं कि अनुकूलन कभी भी जूनियर्स का काम नहीं रहा है। अनुकूलन को हमेशा यह समझने की आवश्यकता होती है कि उपकरण कैसे काम करता है। और अगर ~ 8 गुना ( Naive Parallel vs MemoryJoin ) द्वारा त्वरण प्राप्त करने का अवसर है, तो मैं 2 अंक और प्रलेखन मास्टर करूंगा।

और अंत में, आरेख:

समय बिताया। केवल 4 विधियों ने 10 मिनट से कम समय में कार्य पूरा किया, और मेमोरीजोन एकमात्र ऐसा तरीका है जिसने 10 सेकंड से कम समय में कार्य पूरा किया है।

मेमोरी की खपत। मल्टीपल कंटेस्टेंट्स को छोड़कर सभी तरीकों में लगभग एक ही मेमोरी खपत दिखाई गई। यह डेटा की राशि वापस आने के कारण है।

पढ़ने के लिए धन्यवाद!