মাইএসকিউএল যুক্তিযুক্তভাবে কয়েক বিলিয়ন সারিগুলিতে প্রশ্নগুলি সম্পাদন করতে পারে?

Question

আমি একটি মাইএসকিউএল ডাটাবেসে একটি ভর স্পেকট্রোমিটার থেকে স্ক্যানগুলি সংরক্ষণের পরিকল্পনা করছি এবং এই পরিমাণ ডেটা সংরক্ষণ এবং বিশ্লেষণ দূরবর্তীভাবে সম্ভব কিনা তা জানতে চাই। আমি জানি পরিবেশের উপর নির্ভর করে পারফরম্যান্স বিভিন্নভাবে পরিবর্তিত হয়, তবে আমি মোটামুটি আকারের সন্ধান করছি: ক্যোরিয়াসটি 5 দিন বা 5 মিলিসেকেন্ডে লাগবে?

ছক পূরণ করা

প্রতিটি ইনপুট ফাইলটিতে স্পেকট্রোমিটারের একক রান থাকে; প্রতিটি রান স্ক্যানের একটি সেট নিয়ে গঠিত, এবং প্রতিটি স্ক্যানে ডেটাপয়েন্টগুলির একটি আদেশযুক্ত অ্যারে থাকে। এখানে কিছুটা মেটাডেটা রয়েছে, তবে বেশিরভাগ ফাইলটি অ্যারে 32- বা 64-বিট ইনট বা ভাসমান নিয়ে গঠিত।

হোস্ট সিস্টেম

| ---------------- + + ------------------------------- |
| ওএস | উইন্ডোজ 2008-বিট |
| মাইএসকিউএল সংস্করণ | 5.5.24 (x86_64) |
| সিপিইউ | 2x জিয়ন ই 5420 (মোট 8 টি কোর) |
| র‌্যাম | 8 জিবি |
| এসএসডি ফাইল সিস্টেম | 500 জিআইবি |
| এইচডিডি রেড | 12 টিআইবি |
| ---------------- + + ------------------------------- |

উপেক্ষিত প্রসেসরের সময় ব্যবহার করে সার্ভারে আরও কিছু পরিষেবা চলছে।

ফাইলের পরিসংখ্যান

| ------------------ + + -------------- |
| ফাইল সংখ্যা | ,000 16,000 |
| মোট আকার | 1.3 টিআইবি |
| মিনিট আকার | 0 বাইট |
| সর্বাধিক আকার | 12 জিআইবি |
| গড় | 800 এমআইবি |
| মিডিয়ান | 500 এমআইবি |
| মোট ডেটাপয়েন্টস | Billion 200 বিলিয়ন |
| ------------------ + + -------------- |

মোট ডেটাপয়েন্টগুলির সংখ্যা একটি খুব রুক্ষ অনুমান।

প্রস্তাবিত স্কিমা

আমি কিছু "অধিকার" (অর্থাত পাগল মত ডেটা স্বাভাবিক) করছেন এবং তাই একটি হবে পরিকল্পনা করছি runsটেবিল, একটা spectraকরার জন্য একটি বিদেশী কী দিয়ে টেবিল runs, এবং একটি datapointsএকটি বিদেশী কী দিয়ে টেবিল spectra।

200 বিলিয়ন ডেটাপয়েন্ট প্রশ্ন

আমি একাধিক বর্ণালী এবং সম্ভবত এমনকি একাধিক রান জুড়ে বিশ্লেষণ করতে যাচ্ছি, ফলে কোয়েরিগুলি মিলিয়ন লক্ষ সারি স্পর্শ করতে পারে। ধরে নিচ্ছি আমি সবকিছু ঠিকঠাকভাবে সূচক করেছি (যা অন্য প্রশ্নের জন্য একটি বিষয়) এবং পুরো নেটওয়ার্ক জুড়ে কয়েক'শ এমআইবি বদলানোর চেষ্টা করছি না, এটি মাইএসকিউএলকে হ্যান্ডেল করা কি দূরবর্তীভাবে প্রশংসনীয়?

অতিরিক্ত তথ্য

এক্সএমএল-ভিত্তিক এমজেএমএল ফর্ম্যাটে স্ক্যানের ডেটা ফাইল থেকে আসবে । এই ফর্ম্যাটটির মাংস সেই <binaryDataArrayList>উপাদানগুলিতে রয়েছে যেখানে ডেটা সঞ্চিত থাকে। প্রতিটি স্ক্যান> = 2 <binaryDataArray>উপাদান তৈরি করে যা একত্রে ফর্মের একটি 2-মাত্রিক (বা আরও) অ্যারে গঠন করে [[123.456, 234.567, ...], ...]।

এই ডেটাগুলি একবারে লেখার জন্য, তাই আপডেট সম্পাদনা এবং লেনদেনের সুরক্ষা উদ্বেগ নয়।

একটি ডাটাবেস স্কিমার জন্য আমার নির্বোধ পরিকল্পনাটি হ'ল:

runs টেবিল

| কলামের নাম | প্রকার |
| ------------- + + ------------- |
| আইডি | প্রাথমিক কী |
| সূচনা_কাল | টাইমস্ট্যাম্প |
| নাম | ভোচারার |
| ------------- + + ------------- |

spectra টেবিল

| কলামের নাম | প্রকার |
| ---------------- + + ------------- |
| আইডি | প্রাথমিক কী |
| নাম | ভোচারার |
| সূচী | আইএনটি |
| বর্ণালী_প্রকার | আইএনটি |
| উপস্থাপনা | আইএনটি |
| রান_আইডি | বিদেশী কী |
| ---------------- + + ------------- |

datapoints টেবিল

| কলামের নাম | প্রকার |
| ------------- + + ------------- |
| আইডি | প্রাথমিক কী |
| বর্ণালী_আইডি | বিদেশী কী |
| এমজেড | ডাবল |
| num_counts | ডাবল |
| সূচী | আইএনটি |
| ------------- + + ------------- |

এটা কি যুক্তিসঙ্গত?

---

সুতরাং, আপনি যেমন অনুমান করতে সক্ষম হয়েছিলেন, আমি প্রোগ্রামার, ল্যাবটিতে জীববিজ্ঞানী নই, তাই আমি বিজ্ঞানকে প্রায় ততটা জানি না এবং প্রকৃত বিজ্ঞানীরাও জানেন না।

আমি যে ধরণের ডেটা নিয়ে কাজ করব তার একক বর্ণালী (স্ক্যান) এর একটি প্লট এখানে রয়েছে:

সফটওয়্যারটির লক্ষ্য হ'ল চূড়াগুলি কোথায় এবং কত তাৎপর্যপূর্ণ তা নির্ধারণ করা। এখনই এটি বের করার জন্য আমরা মালিকানাধীন সফ্টওয়্যার প্যাকেজটি ব্যবহার করি, তবে আমরা আমাদের নিজস্ব বিশ্লেষণ প্রোগ্রামটি লিখতে চাই (আরে) যাতে আমরা জানতে পারি যে শিটগুলির নিচে হেক কী চলছে। যেমন আপনি দেখতে পাচ্ছেন, প্রচুর উপাত্ত অবিস্মরণীয়, তবে আমরা আমাদের অ্যালগরিদম মিস করা সম্ভাব্য-দরকারী ডেটা ফেলে দিতে চাই না। আমাদের যখন সম্ভাব্য শিখরগুলির একটি তালিকা পাওয়া যায় যা দিয়ে আমরা সন্তুষ্ট হয়ে যাই, বাকী পাইপলাইন ডেটাপয়েন্টগুলির কাঁচা তালিকার পরিবর্তে সেই শীর্ষ তালিকাটি ব্যবহার করবে। আমি অনুমান করি যে এটি কাঁচা ডেটাপয়েন্টগুলিকে একটি বড় অঙ্কুর হিসাবে সংরক্ষণ করার জন্য যথেষ্ট হবে, তাই প্রয়োজন হলে এগুলি পুনঃব্যবস্থা করা যেতে পারে, তবে কেবল পৃথক ডাটাবেস এন্ট্রি হিসাবে কেবল শিখরগুলি রাখুন। সেক্ষেত্রে স্পেকট্রামে কেবল কয়েক ডজন শৃঙ্গ থাকবে, তাই পাগল স্কেলিং স্টাফ উচিত নয় '

Comments

মাইএসকিউএল দিয়ে স্কেলিংয়ে ফেসবুক

— বেন ব্রোকা

যেহেতু এটি কাঁচা A / D পোলিং ভর স্পেকট্রোমিটার ডেটা, তাই এটি ডেটাবেসে সংরক্ষণ করার জন্য এটি সত্যিই বোবা বলে মনে হচ্ছে। আমি আমার কাঁচা ডেটা নেব, এটি ডাম্প করব, এটি প্রক্রিয়া করব এবং প্রক্রিয়াজাত ফলাফলগুলি একটি ডাটাবেসে সংরক্ষণ করব। ফলাফলগুলি হবে (ক) তরঙ্গরূপগুলি প্রতি সারিতে একটি তরঙ্গরূপ সংরক্ষণ করে, (খ) সেই তরঙ্গকারীর সাথে সম্পর্কিত অন্যান্য ডেটা যেমন ক্যালিব্রেশন বক্ররেখা এবং (গ) ফলাফল ডাটাবেসে সারি। এটি আপনার নকশা থেকে কোটি কোটি সারি ফোলা কাটাবে। আপনি যখন কোনও প্রাথমিক বিশ্লেষণ পুনরায় চালাতে চান, আপনি কার্যকরভাবে কিছু পরামিতিগুলি সম্পাদনা করবেন, একটি বিশাল আকারের গণনা ক্রিয়াকলাপ পরিচালনা করবেন এবং নতুন ফলাফল ডিবিতে সংরক্ষণ করবেন।

— ওয়ারেন পি

Answer 1

আমি আপনার প্রয়োজনের সাথে খুব বেশি পরিচিত নই তবে সম্ভবত ডাটাবেসে প্রতিটি ডেটা পয়েন্ট সংরক্ষণ করা কিছুটা ওভারকিল। এটি প্রায় প্রতিটি পিক্সেলকে একটি সম্পর্কিত ডেটাবেসে পৃথক রেকর্ড হিসাবে সংরক্ষণ করে একটি চিত্র গ্রন্থাগার সংরক্ষণের পদ্ধতির গ্রহণের মতো বলে মনে হচ্ছে।

একটি সাধারণ নিয়ম হিসাবে, ডাটাবেসে বাইনারি ডেটা সংরক্ষণ করা বেশিরভাগ সময় ভুল। সমস্যা সমাধানের জন্য সাধারণত আরও ভাল উপায় থাকে। যদিও রিলেশনাল ডাটাবেসে বাইনারি ডেটা সংরক্ষণ করা সহজাত ভুল নয়, প্রায়শই অসুবিধাগুলি লাভের চেয়ে বেশি হয়। নাম সম্পর্কিত হিসাবে সম্পর্কিত সম্পর্কিত ডাটাবেসগুলি সম্পর্কিত তথ্য সংরক্ষণের জন্য সবচেয়ে উপযুক্ত for বাইনারি ডেটা আপেক্ষিক নয়। এটি ডাটাবেসে আকার (প্রায়শই উল্লেখযোগ্যভাবে) যুক্ত করে, কার্যকারিতা ক্ষতি করতে পারে এবং বিলিয়ন-রেকর্ড মাইএসকিউএল ইনস্ট্যান্স বজায় রাখার বিষয়ে প্রশ্ন আসতে পারে। সুসংবাদটি হ'ল এখানে বাইনারি ডেটা সংরক্ষণের জন্য বিশেষভাবে উপযোগী ডাটাবেস রয়েছে। এর মধ্যে একটি, সর্বদা সহজেই দৃশ্যমান না হওয়ার পরেও আপনার ফাইল সিস্টেমটি! কেবল আপনার বাইনারি ফাইলগুলির জন্য একটি ডিরেক্টরি এবং ফাইল নামকরণ কাঠামো নিয়ে আসুন,

অন্য পদ্ধতিটি আপনার ডেটাপয়েন্টগুলি (এবং সম্ভবত স্পেকট্রা) ডেটার জন্য একটি ডকুমেন্ট-ভিত্তিক স্টোরেজ সিস্টেম ব্যবহার করা এবং রানগুলির জন্য মাইএসকিউএল ব্যবহার করা (বা সম্ভবত অন্যদের মতো রানগুলি একই ডিবিতে লাগানো)।

Comments

কেন একটি ডাটাবেসে বাইনারি ডেটা সংরক্ষণ করা ভুল বলে বিবেচিত হয়? (আংশিকভাবে জিজ্ঞাসা করা কারণ আমি কৌতূহলী তবে এটির জন্য আমি কোনও ব্যবহারের ক্ষেত্রে ভাবতে পারি))

যদি বাইনারি ডেটার স্বতন্ত্রভাবে কোনও মান না থাকে তবে এটি কোনও অনন্য সারি হিসাবে সংরক্ষণ করা উচিত নয়। একটি চিত্রের পিক্সেল 500x325 অপ্রাসঙ্গিক।

এটি একটি খুব ভাল পয়েন্ট। আমাদের পরে যদি আবার জিনিসগুলি বাইরে টানা প্রয়োজন হয় তবে আমাদের সম্ভবত কাঁচা ফাইলগুলি রাখা উচিত, তবে চিত্রগুলি সংরক্ষণ করার উপমাটি দুর্দান্ত। আমাদের আর কোনও ডেটাপয়েন্টে অ্যাক্সেসের প্রয়োজন হবে না (যদি না আমরা শীর্ষের এক্সট্রাকশনটি পুনরায় করবো), সুতরাং কেবল সরানো পরিসংখ্যানের তথ্য সংরক্ষণ করা আরও ভাল।

— হ্যাক্সনি

Answer 2

আমি একবার খুব বড় (টেরাবাইট +) মাইএসকিউএল ডাটাবেস নিয়ে কাজ করেছি। আমাদের কাছে থাকা বৃহত্তম টেবিলটি ছিল আক্ষরিক অর্থে এক বিলিয়ন সারি। এটি মাইএসকিউএল 5.0 ব্যবহার করছিল, সুতরাং সম্ভবত জিনিসগুলি উন্নতি হতে পারে।

এটা কাজ করেছে. মাইএসকিউএল বেশিরভাগ সময় সঠিকভাবে ডেটা প্রসেস করে। যদিও এটি চূড়ান্তভাবে অনস্বাস্থ্যকর ছিল। (যদি আপনি একটি টেরাবাইট ডেটা সহ ছয় সিগমা-স্তরের উপলব্ধতা চান তবে মাইএসকিউএল ব্যবহার করবেন না We আমরা একটি স্টার্টআপ ছিলাম যার কোনও ডিবিএ এবং সীমিত তহবিল ছিল না))

কেবল ডেটা ব্যাক আপ করা এবং ডেটা সংরক্ষণ করা একটি চ্যালেঞ্জ ছিল। আমাদের প্রয়োজন হলে টেবিলটি পুনরুদ্ধার করতে কয়েক দিন লাগবে।

আমাদের 10-100 মিলিয়ন সারি ব্যাপ্তিতে অসংখ্য সারণী ছিল। টেবিলগুলিতে যে কোনও উল্লেখযোগ্য যোগ দেয় খুব বেশি সময় ব্যয়কারী এবং চিরকালের জন্য গ্রহণ করবে। সুতরাং আমরা টেবিলগুলি 'ওয়াক' করার জন্য সঞ্চিত প্রক্রিয়া লিখেছিলাম এবং আইডি এর ব্যাপ্তিগুলির বিপরীতে যোগদান করে। এইভাবে আমরা এক সাথে 10-100,000 সারি ডেটা প্রসেস করব (আইডির 1-100,000 তারপর 100,001-200,000 ইত্যাদির বিপরীতে যোগ দিন)। পুরো টেবিলের বিপরীতে যোগদানের তুলনায় এটি উল্লেখযোগ্যভাবে দ্রুত ছিল।

প্রাইমারি কী-এর ভিত্তিতে নয় এমন খুব বড় টেবিলগুলিতে সূচী ব্যবহার করা আরও অনেক কঠিন। মাইএসকিএল 5.0 সূচকগুলি দুটি টুকরোতে সঞ্চয় করে - এটি সূচকগুলি (প্রাথমিক সূচক ব্যতীত) প্রাথমিক কী মানগুলিতে সূচক হিসাবে সঞ্চয় করে। সুতরাং সূচিকৃত লুক্কুয়ালগুলি দুটি অংশে করা হয়: প্রথম মাইএসকিউএল একটি সূচকে যায় এবং এটি থেকে যে মূল কী মানগুলি সন্ধান করা দরকার তা সেখান থেকে টান দেয়, তারপরে সেই মানগুলি কোথায় তা খুঁজে বের করার জন্য এটি প্রাথমিক কী সূচকটিতে দ্বিতীয় সন্ধান করে।

এর নেটটি হ'ল খুব বড় টেবিলের জন্য (1-200 মিলিয়ন প্লাস সারি) সারণীর বিপরীতে সূচীকরণ আরও সীমাবদ্ধ। আপনার কম, সহজ সূচী প্রয়োজন। এবং এমনকী সরল নির্বাচনের বিবৃতি যা সরাসরি কোনও সূচকে না থাকে তা কখনই ফিরে আসতে পারে না। যেখানে ধারাগুলি অবশ্যই সূচকগুলি হিট করতে হবে বা এটি ভুলে যেতে হবে।

তবে যা বলা হচ্ছে, জিনিসগুলি আসলে কাজ করেছিল। আমরা এই খুব বড় টেবিলগুলির সাথে মাইএসকিউএল ব্যবহার করতে সক্ষম হয়েছি এবং গণনা করতে এবং সঠিক উত্তরগুলি পেয়েছি।

200 বিলিয়ন সারি ডেটা বিশ্লেষণ করার চেষ্টা করার জন্য খুব হাই-এন্ড হার্ডওয়্যার এবং প্রচুর হ্যান্ড হোল্ডিং এবং ধৈর্য প্রয়োজন। আপনি যে ফর্ম্যাট থেকে পুনরুদ্ধার করতে পারবেন কেবলমাত্র সেই ডেটাটিকে ব্যাক আপ করা একটি গুরুত্বপূর্ণ কাজ হবে।

আমি শ্রীনি.এভিগাল্লার উত্তরের সাথে একমত যে পাগলের মতো ডেটা স্বাভাবিক করা এখানে ভাল ধারণা নাও হতে পারে। অনেক বেশি টেবিলের সাথে একাধিক টেবিল জুড়ে গেলে ফাইল ফাইলের ঝুঁকির মুখোমুখি হয়ে যায় যার অর্থ আপনার কিছু প্রশ্ন আবার কখনও ফিরে আসতে পারে না। সাধারণ, পূর্ণসংখ্যার কীগুলির সাহায্যে ডেনোরমলাইজিং আপনাকে সাফল্যের আরও ভাল সুযোগ দেয়।

আমাদের যা কিছু ছিল তা InnoDB ছিল। মাইআইএসএএম বনাম আইএনএনডিবি সম্পর্কিত: মূল বিষয়টি হ'ল দুটি মেশানো না। মাইএসকিউএল যেভাবে কী এবং অন্যান্য ডেটা ক্যাশে করে সে কারণে আপনি উভয়ের জন্যই কোনও সার্ভারকে সত্যিই অনুকূলিত করতে পারবেন না। আপনি যদি পারেন তবে সার্ভারের সমস্ত টেবিলের জন্য একটি বা অন্যটি চয়ন করুন। মাইআইএসএএম কিছু গতির সমস্যাগুলির সাথে সহায়তা করতে পারে, তবে এটি করা প্রয়োজন ডিবিএর সামগ্রিক কাজে - এটি হত্যাকারী হতে পারে help

Comments

মাইএসকিউএল 5.0 থেকে সূচী (...) বিভাগে অনেক উন্নতি করেছে। এটি এখন কীভাবে আচরণ করে তা দেখতে আকর্ষণীয় হবে।

— রিং Ø

Answer 3

পাগলের মতো তথ্যকে স্বাভাবিককরণ

পাগলের মতো ডেটা সাধারণ করা এই ক্ষেত্রে সঠিক কৌশল নাও হতে পারে। আপনার প্রয়োগগুলিকে উভয়ই সাধারণ আকারে এবং আপনার অ্যাপ্লিকেশনটির জন্য উপযুক্ত উপকরণযুক্ত দর্শন আকারে সঞ্চয় করে আপনার বিকল্পগুলি খোলা রাখুন। এই ধরণের অ্যাপ্লিকেশনগুলির মূল হ'ল অ্যাডহক ক্যোয়ারী লেখা না। ডেটা মডেলিংয়ের চেয়ে ক্যোয়ারী মডেলিং বেশি গুরুত্বপূর্ণ। আপনার টার্গেট অনুসন্ধানগুলি দিয়ে শুরু করুন এবং সর্বোত্তম ডেটা মডেলের দিকে কাজ করুন।

Is this reasonable?

আমি সমস্ত ডেটা সহ একটি অতিরিক্ত ফ্ল্যাট টেবিল তৈরি করব।

run_id | spectrum_id | data_id | <data table columns..> |

আমি এই টেবিলটি সমস্ত প্রশ্নের প্রাথমিক উত্স হিসাবে ব্যবহার করব। কারণটি হ'ল কোনও যোগদান করতে হবে। ইনডেক্সিং ব্যতীত যোগদানগুলি আপনার সিস্টেমটিকে অত্যন্ত ব্যবহারযোগ্য করে তুলবে এবং এ জাতীয় বিশাল ফাইলগুলিতে সূচীকরণ সমানভাবে ভয়ানক হবে।

কৌশলটি হ'ল প্রথমে উপরের টেবিলটিতে কোয়েরি করুন, ফলাফলগুলিকে একটি টেম্প টেবিলের মধ্যে ফেলে দিন এবং রান এবং স্পেকট্রামের সারণীগুলির সাথে টেম্প টেবিলটিতে যোগ দিন এবং আপনার পছন্দসই ডেটা পাবেন।

---

আপনি কি আপনার লেখার প্রয়োজনীয়তা বনাম পড়ার প্রয়োজনগুলি বিশ্লেষণ করেছেন? এটি এসকিউএল খনন এবং অ-মানক ডেটা স্টোরেজ মেকানিজমে যেতে খুব লোভনীয় হবে। আমার দৃষ্টিতে এটি শেষ সমাধান হওয়া উচিত।

লেখার গতি ত্বরান্বিত করতে, আপনি হ্যান্ডলার সকেট পদ্ধতিটি চেষ্টা করতে চাইতে পারেন। পারকোনা, যদি আমার মনে থাকে তবে তাদের ইনস্টল প্যাকেজে প্যাকেজগুলি হ্যান্ডলার সকেট। (পারকোনার সাথে কোনও সম্পর্ক নেই!)

http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html

Answer 4

সংক্ষিপ্ত উত্তরটি একটি হ্যাঁ হ্যাঁ - সারিগুলির সংখ্যার সুনির্দিষ্ট স্কিমা, ডেটাটাইপস এবং আপনি যে ক্রিয়াকলাপগুলি বেছে নিচ্ছেন সেগুলি বেড়ে যায় গুরুত্ব সহকারে।

আপনি আপনার ডেটা কতটা স্বাভাবিক করবেন তা নির্ভর করে আপনি সঞ্চিত ডেটাতে সঞ্চালনের পরিকল্পনাটি পরিচালনা করে। বিশেষত আপনার 'ডেটাপয়েন্টস' সারণীটি সমস্যাযুক্ত বলে মনে হচ্ছে - আপনি কি কোনও অন্য বর্ণের মাসের সাথে কোনও বর্ণালী থেকে নবম পয়েন্ট তুলনা করার পরিকল্পনা করছেন? তা না হলে এগুলিকে আলাদা করে সংরক্ষণ করা ভুল হতে পারে। যদি আপনার ডেটাপয়েন্টগুলি একা না দাঁড়িয়ে থাকে এবং কেবলমাত্র তাদের সম্পর্কিত স্পট্রাটারের প্রসঙ্গেই বুঝতে পারেন আপনার প্রাথমিক কী দরকার নেই - বর্ণালীর জন্য একটি বিদেশী কী এবং একটি 'নবম' কলাম (আপনার 'সূচী' কলাম?) যথেষ্ট হবে ।

আন্তঃ এবং আন্তঃ-বর্ণালী ক্রিয়াকলাপগুলি সংজ্ঞায়িত করুন আপনার অবশ্যই সম্পাদন করতে হবে এবং তারপরে এটি সম্পাদন করার সবচেয়ে সস্তা উপায়টি খুঁজে বের করতে হবে। যদি সাম্যতা কেবলমাত্র প্রয়োজন হয় তবে তারা অস্বীকৃত হতে পারে - সম্ভবত কিছু প্রাক-গণনা করা পরিসংখ্যান মেটাডেটা যা আপনার ক্রিয়াকলাপকে সহায়তা করে। স্বতন্ত্র ডেটাপয়েন্টগুলিতে আপনার যদি সম্পূর্ণ এস -কিউএল অ্যাক্সেসের প্রয়োজন হয় তবে আপনি প্রতিটি সারিটির আকার খালি ন্যূনতম সংখ্যার ক্ষেত্র এবং সম্ভাব্যতম ক্ষুদ্রতম ডেটাটাইপ হ্রাস করার বিষয়টি নিশ্চিত করেছেন।

বৃহত্তম ব্যক্তিগত মাইএসকিউএল আমি ব্যক্তিগতভাবে পরিচালনা করেছি ~ 100 মিলিয়ন সারি। এই আকারে আপনি নিজের সারিগুলি রাখতে চান এবং এইভাবে আপনার ক্ষেত্রগুলি স্থির-আকারে রাখতে চান - এটি মাইএসকিউএলকে সারণীর যে কোনও সারির অবস্থান দক্ষতার সাথে প্রতিটি সারির নির্দিষ্ট আকারের গুণনের গুণমান গণনা করতে দেয় (পয়েন্টার পাটিগণিত ভাবেন) - যদিও সঠিক বিবরণ নির্ভর করে আপনি কোন স্টোরেজ ইঞ্জিন ব্যবহারের পরিকল্পনা করছেন। আপনি এটি থেকে দূরে সরে যেতে পারলে মাইআইএসএএম ব্যবহার করুন, এটির নির্ভরযোগ্যতার অভাব যা এটির গতিতে তৈরি করে, এবং আপনার পরিস্থিতিতে এটি যথেষ্ট হওয়া উচিত should ভেরিয়েবল-আকারের ক্ষেত্রগুলি যেমন CHAR (n) এর সাথে VARCHAR প্রতিস্থাপন করুন এবং আপনার পঠিত প্রশ্নের উপর আরটিআরআইএম () ব্যবহার করুন।

একবার আপনার টেবিলের সারিগুলি স্থির-প্রশস্ত হয়ে গেলে আপনি মাইএসকিউএল এর পূর্ণসংখ্যার ডেটাটাইপগুলি সাবধানতার সাথে মূল্যায়ন করে বাইটের সংখ্যা হ্রাস করতে পারবেন (যার কয়েকটি অ-মানক)। প্রতি 1-বাইট সঞ্চয় আপনি 4-বাইট INT কে 3-বাইট মিডিয়ামিন্টে রূপান্তর করে আউট করতে পারেন আপনার প্রতি মিলিয়ন সারিতে 1MB ডলার সাশ্রয় করে - যার অর্থ কম ডিস্ক I / O এবং আরও কার্যকর ক্যাশে। সবচেয়ে ছোট সম্ভব ডেটাটাইপগুলি ব্যবহার করুন যা আপনি এড়াতে পারেন । সাবধানে ফ্লোটিং পয়েন্ট ধরনের মূল্যায়ন এবং যদি আপনি 4-বাইট floats বা এমনকি <8 বাইট সঙ্গে 8-বাইট দ্বিগুণ প্রতিস্থাপন করতে পারেন দেখতে নির্দিষ্ট বিন্দু NUMERICs । আপনি যা যা চয়ন করেন তা আপনাকে পরে কামড়ায় না তা নিশ্চিত করার জন্য পরীক্ষা চালান।

আপনার ডেটাসেটের প্রত্যাশিত বৈশিষ্ট্য এবং প্রয়োজনীয় ক্রিয়াকলাপগুলির উপর নির্ভর করে আপনার মানগুলির আরও অস্বাভাবিক এনকোডিংগুলিতে আরও সঞ্চয় থাকতে পারে (প্রত্যাশিত নিদর্শন / পুনরাবৃত্তি যা মানগুলির একটি সংকেতে সূচক হিসাবে এনকোড করা যেতে পারে, কাঁচা ডেটা যা কেবল অর্থবহভাবে অবদান রাখতে পারে মেটাডেটা এবং ফেলে দেওয়া হবে ইত্যাদি) - যদিও বহিরাগত, অদম্য, ধ্বংসাত্মক অপ্টিমাইজেশন কেবল তখনই সার্থক যখন অন্য প্রতিটি বিকল্প চেষ্টা করা হয়েছে।

সর্বাধিক গুরুত্বপূর্ণ বিষয়, আপনি যে কাজটি শেষ করেছেন তা বিবেচনা করেই বিবেচনা করবেন না যে আপনি নিখুঁত স্কিমাটি বেছে নিয়েছেন এবং অন্ধভাবে 10 লক্ষ লক্ষ রেকর্ড ডাম্পিং শুরু করবেন begin ভাল ডিজাইনগুলি বিকশিত হতে সময় নেয়। একটি বিশাল তবে পরিচালনাযোগ্য (বলুন, 1-5%) পরীক্ষার ডেটার সেট তৈরি করুন এবং আপনার স্কিমার যথার্থতা এবং কার্যকারিতা যাচাই করুন। বিভিন্ন অপারেশন কীভাবে সম্পাদন করে তা দেখুন (http://dev.mysql.com/doc/refman/5.0/en/using-explain.html) এবং সর্বাধিক ঘন ঘন অপারেশনগুলির পক্ষে আপনার স্কিমার ভারসাম্য বজায় রাখার বিষয়টি নিশ্চিত করুন।

আমি কি ছোট বললাম? উপস। যাই হোক, শুভকামনা!

Answer 5

এটি মনে হবে যে এক্সএমএল থেকে ডেটা পয়েন্টের ডেটাগুলি ছড়িয়ে দেওয়ার (সময় এবং রানের মতো মেটাডাটার বিপরীতে) এবং একটি ডাটাবেস ফর্মের একমাত্র কারণ হ'ল আপনি যখন অ্যারে জুড়ে বর্ণালী বিশ্লেষণ করছেন - সম্ভবত সমস্তগুলি সন্ধান করছেন একটি নির্দিষ্ট স্বাক্ষর দিয়ে চলে। কেবলমাত্র আপনি এখনই আপনার সমস্যার ডোমেনটি জানেন তবে এটি প্রতি সারি 1 টি নমুনা সহ 96kHz এ সংগীত স্যাম্পেল করার মতো হতে পারে। আমি নিশ্চিত না যে আকার কীভাবে ডেটা ব্যবহৃত হয় তার চেয়ে বেশি সমস্যা। ডেটা জুড়ে জিজ্ঞাসা করা বিটলসের সমস্ত গানে গানটির জন্য 2 মিনিট আপেক্ষিক প্রশস্ততা জিজ্ঞাসার সমতুল্য। কোন ধরণের বিশ্লেষণগুলি করা হতে পারে তা যদি আপনি জানেন তবে এটি সম্ভব যে সংকেতগুলিতে এগুলি সম্পাদন করা এবং মেটাডাটাতে রান সম্পর্কে সংরক্ষণের বিষয়টি আরও অর্থবোধ করতে পারে।

আপনার উত্স ডেটা অপ্রয়োজনীয় কিনা তাও আমি নিশ্চিত নই। এটি সম্পূর্ণভাবে সম্ভব যে ডাটাবেসের বর্ণালীতে কেবল শূন্য-এন্ট্রি অন্তর্ভুক্ত করা উচিত যখন মূল এক্সএমএলে শূন্য-এন্ট্রি অন্তর্ভুক্ত থাকে এবং সুতরাং আপনার সামগ্রিক সারিগুলির সংখ্যা উত্সের তথ্যের তুলনায় অনেক কম হতে পারে।

সুতরাং, অনেক প্রশ্নের মত, মাইএসকিউএল আপনার মডেলটি পরিচালনা করছে এমন বিষয়ে জিজ্ঞাসা করার আগে, পিছনে পদক্ষেপে এবং মডেলটির দিকে তাকিয়ে এবং এটি কীভাবে ব্যবহৃত হবে তা পারফরম্যান্স সম্পর্কে চিন্তিত হওয়ার চেয়ে সম্ভবত আরও উপযুক্ত।

---

আপনার প্রশ্ন আপডেটগুলি পর্যালোচনা করার পরে, আমি মনে করি যে একটি মডেল যেখানে বাইনারি ডেটা একটি বিএলওবি হিসাবে সংরক্ষণ করা হয় বা কেবলমাত্র ফাইলটির পয়েন্টারই যথেষ্ট এবং আপনার মডেলটি উল্লেখযোগ্য শিখরগুলি সম্পর্কিত তথ্য সংরক্ষণ করার জন্য কাজ করে যা ডেটা প্রথম যখন চিহ্নিত করা হয়েছিল পড়ুন।

Answer 6

আমি প্রায় 50 টি ডাটাবেস সার্ভারের সাথে একটি ওয়েব অ্যানালিটিক্স পরিষেবা চালিত করি, যার প্রত্যেকটিতে 100 মিলিয়ন সারি এর বেশি অনেকগুলি সারণী থাকে এবং এমন একাধিক যা প্রায় এক বিলিয়ন সারি হতে থাকে, কখনও কখনও দুই বিলিয়ন (প্রতিটি সার্ভারে) থাকে।

এখানে পারফরম্যান্স ঠিক আছে। এটি খুব স্বাভাবিক তথ্য। তবে - এটি পড়ার সাথে আমার প্রধান উদ্বেগ হ'ল আপনি এই টেবিলগুলির জন্য 4.2 বিলিয়ন সারি চিহ্নের চেয়ে ভাল হয়ে উঠবেন (সম্ভবত "রান" নয় তবে সম্ভবত অন্য দুটি), যার অর্থ আপনার জন্য INT এর পরিবর্তে BIGINT ব্যবহার করা দরকার প্রাথমিক / বিদেশী কীগুলি।

ইনডের তুলনায় একটি সূচকযুক্ত কলামে বিগিন্ট ক্ষেত্রগুলির সাথে মাইএসকিউএল সম্পাদনা হাস্যকরভাবে ভয়াবহ । আমি একবারে কোনও টেবিল দিয়ে এটি করার ভুল করেছিলাম বলে আমি ভেবেছিলাম এই আকারটি আরও বেড়ে যেতে পারে এবং এটি কয়েকশ মিলিয়ন সারি মারার পরে পারফরম্যান্সটি কেবল অস্বাভাবিক হয়ে যায়। আমার কাছে কাঁচা সংখ্যা নেই তবে আমি যখন খারাপ বলি, তার মানে উইন্ডোজ এমই খারাপ।

এই কলামটি প্রাথমিক কী ছিল। আমরা এটিকে আবার কেবল একটি আইএনটি এবং প্রেস্টো ম্যাজিকোতে রূপান্তর করেছি, পারফরম্যান্সটি আবার ভাল ছিল।

তখন আমাদের সমস্ত সার্ভারগুলি ডেবিয়ান 5 এবং মাইএসকিউএল 5.0 এর সাথে ছিল। আমরা এরপরে ডেবিয়ান 6 এবং পারকোনা মাইএসকিউএল 5.5-তে আপগ্রেড করেছি, সুতরাং তখন থেকে জিনিসগুলির উন্নতি হতে পারে। তবে এখানে আমার অভিজ্ঞতার ভিত্তিতে, না, আমি মনে করি না এটি খুব ভালভাবে কাজ করবে।

Answer 7

এটি কার্যকর কিনা বা না, আপনি সর্বদা একক একক স্টোরেজ মিডিয়াম দিয়ে একই সমস্যায় চলে যাবেন: ডিস্কগুলি ধীরে ধীরে। 100 এমবি / সেকেন্ডে (স্পিনিং মিডিয়াতে বেশ ভাল) এটি 1 টিবি টেবিল পড়তে কেবল 3 ঘন্টা সময় নেয় ; এটি কোনও বিশ্লেষণ ধরে নেই বা সন্ধান করছে না বা অন্যান্য বিলম্ব আপনাকে ধীর করবে।

এ কারণেই প্রায় প্রতিটি "বিগ ডেটা" ইনস্টলেশনটি কোনও ধরণের বিতরণকৃত ডেটা স্টোর ব্যবহার করে। আপনার ডিবি চালানোর জন্য একটি দুর্দান্ত আশ্চর্যজনক কম্পিউটার তৈরির জন্য আপনি 8 গুণ বেশি অর্থ ব্যয় করতে পারেন, তবে আপনার যদি সমান্তরালে স্ক্যান করা যায় এমন অনেকগুলি ডেটা থাকে তবে আপনি 8 টি সস্তা কম্পিউটারে লোড বিতরণ করা থেকে প্রায় সর্বদা ভাল better

হাদুপের মতো প্রকল্পগুলি বিশেষত এর মতো উদ্দেশ্যে নির্মিত হয়েছিল। আপনি সস্তা কম্পিউটারগুলির পুরো গুচ্ছের একটি গোষ্ঠী তৈরি করেন, সেগুলির সমস্তগুলিতে ডেটা বিতরণ করেন এবং তাদের সমান্তরালে জিজ্ঞাসা করেন। এটি একই ধারণাটির চারপাশে নির্মিত প্রায় দেড় ডজন সমাধানগুলির মধ্যে একটি, তবে এটি একটি খুব জনপ্রিয়।

Answer 8

এইচএম ... আমি এই দুটি কারণ দেখছি আপনি কেন এই ধরণের ডেটা কাঠামো বেছে নেবেন:

• আপনার যে কোনও ডেটাপয়েন্ট ক্যোয়ারী বনাম কোনও ডেটাপয়েন্ট করতে হবে
• আপনি এসকিউএল আপনার সমস্ত যুক্তি সম্পাদন করার মনস্থ করা

এখন, আমি আপনার প্রয়োজনীয়তাগুলিতে দীর্ঘ কঠোর নজর দেওয়ার পরামর্শ দিচ্ছি এবং উপরোক্ত অনুমানগুলির মধ্যে কমপক্ষে একটি সত্য কিনা তা যাচাই করব। যদি উভয়ই সত্য না হয় তবে আপনি জিনিসগুলিকে স্লো করে তুলছেন। এই জাতীয় ডেটাসেটের জন্য, আমি প্রথমে ডেটা কীভাবে অ্যাক্সেস করা হবে, আপনার কী ধরণের নির্ভুলতা প্রয়োজন হবে ইত্যাদি সন্ধান করার পরামর্শ দেব - এবং তারপরে আপনার ডাটাবেসটি ডিজাইন করুন।

পিএস: মনে রাখবেন যে আপনার প্রতি ডাটা পয়েন্টে কমপক্ষে 36 + 5 বাইটের প্রয়োজন হবে, তাই 200B ডেটাপয়েন্ট সহ যা আপনাকে কমপক্ষে 8.2 টিবি প্রয়োজনীয় স্থান দেয়।

পিপিএস: আপনার টেবিলের idকলামের প্রয়োজন নেই datapoints, PRIMARY KEY (spectrum_id, index)সম্ভবত যথেষ্ট পরিমাণে (কেবল সাবধান থাকুন যে indexকোনও সংরক্ষিত শব্দ হতে পারে)

Answer 9

সম্পাদনা করুন:

একা ডিস্কে স্টোরড ডেটা সহ এটি মাইএসকিউএলে করবেন না। একটি মাত্র মাধ্যম থেকে কেবলমাত্র সেই পরিমাণ ডেটা পড়তে সময় লাগবে। আপনাকে স্কেল আউট করতে হবে, আপ নয়।

আপনি যদি কার্যকর ডেটা বিশ্লেষণ করতে চান তবে আপনাকে অবশ্যই আপনার ডেটাটিকে অস্বীকৃতি জানাতে হবে। আপনি এখানে কোনও অনলাইন সিস্টেম ডিজাইন করছেন না। আপনি সংখ্যার ক্রাচ করতে চান, সেই অনুযায়ী ডিজাইন করুন।

লাইনের নীচে মূল উত্তর

---

উত্তর আপনার প্রশ্নের উপর নির্ভর করে পৃথক হবে, মাইএসকিউএল এই কাজের জন্য সেরা সরঞ্জাম নাও হতে পারে। আপনি সমাধানটি দেখতে চাইতে পারেন আপনি "আপ" না করে "আউট" স্কেল করতে পারেন। আপনি যদি কিছু চেষ্টা করতে চান তবে আপনার হ্যাডোপের মতো মানচিত্র হ্রাস সমাধানের দিকে নজর দেওয়া উচিত।

আপনি যদি আরও অ্যাড-হক প্রশ্নগুলি করতে চান তবে গুগলের বিগকুয়েরি সমাধান আপনার জন্য উপযুক্ত হতে পারে। গুগল আই / ও 2012 থেকে প্রাসঙ্গিক উপস্থাপনা: বিগকুয়ের সাথে বড় ডেটা ক্রাঞ্চ করা

সুতরাং, সমাধানটি নির্ভর করে যদি এটি কোনও শট জিনিস এবং আপনি যদি যুক্তিযুক্তভাবে প্রশ্নগুলি সমর্থন করতে চান তবে।

Answer 10

কেউ আমার পরামর্শ মত উল্লেখ করেনি। কটাক্ষপাত ব্যাপক sharded মাইএসকিউএল সমাধান। উদাহরণস্বরূপ, এটি অত্যন্ত সম্মানিত টাম্বলার উপস্থাপনা দেখুন ।

ধারণাটি হ'ল:

• পরিবর্তে একটি অতিরিক্ত বড় ডাটাবেস
• মূল ডেটার অংশগুলি ধারণ করে অনেকগুলি ছোট ব্যবহার করুন

সুতরাং আপনি উলম্ব কর্মক্ষমতা উন্নত করার পরিবর্তে অনুভূমিকভাবে স্কেল করতে পারেন। গুগলের বিগ টেবিল এবং জিএফএস এছাড়াও ডেটা পেটবাইট সংরক্ষণ এবং জিজ্ঞাসা করার জন্য সস্তা অনুভূমিকভাবে স্কেলেবল নোডগুলি ব্যবহার করছে।

যাইহোক, আপনার যদি বিভিন্ন শার্ডগুলির উপর অনুসন্ধান চালানোর প্রয়োজন হয় তবে সমস্যাগুলি হবে।

---

^{যদি কারও আগ্রহী হয়, আমি কিছুক্ষণ আগে হ্যালো-ওয়ার্ল্ড শর্ডিং অ্যাপ্লিকেশন দিয়েছিলাম। এটি একটি ব্লগ পোস্টে এখানে আলোচনা করা হয়। আমি রাভেনডিবি এবং সি # ব্যবহার করেছি তবে বিবরণ অপ্রাসঙ্গিক এবং ধারণাটি একই।}

Answer 11

কোন ধরণের ডেটা সংরক্ষণ করা যাচ্ছে? এটি কি ভাগ করা স্টোরেজ ডিভাইস?

আপনার ক্যোয়ারির সময় নির্ধারণ করবে এমন চূড়ান্ত কারণটি আপনার হার্ডড্রাইভ হতে চলেছে। ডাটাবেসগুলি এবং তাদের ক্যোয়ারী অপ্টিমাইজারগুলি যতটা সম্ভব ডিস্ক আই / ওএসের সংখ্যা হ্রাস করার জন্য ডিজাইন করা হয়েছে। আপনার কেবলমাত্র 3 টি টেবিল রয়েছে তা দেওয়া, এটি বেশ নির্ভরযোগ্যতার সাথে সম্পন্ন হবে।

একটি হার্ডড্রাইভের পড়ার / লেখার গতি মেমরির গতির চেয়ে 200-300 গুণ বেশি ধীর হতে চলেছে। খুব দ্রুত বিলম্ব এবং দ্রুত পড়ার এবং লেখার গতি সহ হার্ডড্রাইভগুলি সন্ধান করুন। এই সমস্ত ডেটা যদি একটি 2-টিবি ড্রাইভে থাকে, আপনি সম্ভবত কোয়েরিগুলি শেষ করতে দীর্ঘ সময় অপেক্ষা করবেন। হার্ডড্রাইভ লেটেন্সিটি 10-15 মিলিমিল্যান্ড সেকেন্ডে রয়েছে যখন মেমরি ল্যাটেন্সি 10 ন্যানোসেকেন্ডের চেয়ে কম। হার্ডড্রাইভ লেটেন্সি মেমরি ল্যাটেন্সি থেকে 1000-2000x কম হতে পারে। হার্ডড্রাইভটিতে যান্ত্রিক বাহুর সরানো এই পুরো সিস্টেমে খুব কম জিনিস।

আপনার কত র‌্যাম আছে? 16 জিবি? যাক আপনাকে 32 রেকর্ড রাখতে দেয়। আপনার কাছে 16000 ফাইল রয়েছে। আপনি যদি সমস্ত ডেটাপয়েন্টগুলিকে রৈখিক স্ক্যান করতে চলেছেন তবে একা সময় চাইলে আপনি সহজেই 5-10 সেকেন্ড সহ শেষ করতে পারেন। তাহলে স্থানান্তর হার 50mb / s ফ্যাক্টর? প্রায় 7 ঘন্টা। অতিরিক্তভাবে, অস্থায়ীভাবে সংরক্ষিত যেকোন ডেটা নতুন ডেটা পড়ার জন্য জায়গা তৈরি করতে হার্ডডাইভের মধ্যে সংরক্ষণ করতে হবে।

যদি আপনি একটি ভাগ করা স্টোরেজ ডিভাইস ব্যবহার করেন যা সক্রিয়ভাবে অন্যান্য ব্যবহারকারীর দ্বারা ব্যবহৃত হচ্ছে ... আপনার সেরা বেটটি রাতে সবকিছু চালাচ্ছে run

নীস্টযুক্ত প্রশ্নের সংখ্যা হ্রাস করুন এছাড়াও ভাল সাহায্য করে। নেস্টেড ক্যোয়ারীগুলির ফলে অস্থায়ী টেবিলগুলি আসে যা আপনার হার্ডড্রাইভকে আরও বেশি ছড়িয়ে দেবে। আমি আশা করি আপনার হার্ডড্রাইভে আপনার কাছে নিখরচায় মুক্ত জায়গা রয়েছে।

ক্যোয়ারী অপ্টিমাইজেশান একবারে 1 টি ক্যোয়ারিতে দেখতে পারে। সুতরাং নেস্টেড নির্বাচিত বিবৃতিগুলি অনুকূলিত করা যায় না can't তবুও, আপনি যদি কোনও নির্দিষ্ট নেস্টেড ক্যোয়ারী জানেন তবে একটি ছোট ডেটাসেট ফেরত আসবে, এটি রাখুন। ক্যোয়ারী অপ্টিমাইজেশানটি হিস্টোগ্রাম এবং রুক্ষ অনুমানগুলি ব্যবহার করে, যদি আপনি ডেটা এবং কোয়েরি সম্পর্কে কিছু জানেন তবে এগিয়ে যান এবং এটি করুন।

আপনার ডেটা যেভাবে ডিস্কে সঞ্চিত থাকে সে সম্পর্কে আপনি যত বেশি জানেন আপনি তত দ্রুত আপনার প্রশ্নগুলি লিখতে সক্ষম হবেন। সবকিছু যদি প্রাথমিক কীতে ক্রমানুসারে সংরক্ষণ করা থাকে তবে নেস্টেড কোয়েরি থেকে ফিরে আসা প্রাথমিকগুলি কীগুলি বাছাই করা উপকারী হতে পারে। এছাড়াও, আপনি যদি আগে থেকেই বিশ্লেষণের প্রয়োজন ডেটাসেটগুলির সেটটি হ্রাস করতে পারেন তবে এটি করুন। আপনার সিস্টেমের উপর নির্ভর করে আপনি প্রতি ফাইলের মধ্যে ডেটা ট্রান্সফারের প্রায় 1 সেকেন্ডের দিকে তাকান।

যদি আপনি নামের মানগুলি (ভার্চারগুলি) সংশোধন করতে যাচ্ছেন তবে আমি এটিকে সর্বাধিক আকারের সাথে একটি ডেটাটাইপে পরিবর্তন করব, এটি খণ্ডিত হওয়া রোধ করবে এবং বাণিজ্যটি মেমরির মাত্র কয়েক বাইট is সর্বোচ্চ 100 টি সহ একটি এনভিচারচার হতে পারে।

টেবিলটিকে অস্বীকৃতি জানাতে যতদূর মন্তব্য। আমি মনে করি কেবল বৃহত্তর গ্রুপগুলিতে ডেটাপয়েন্টগুলি (সম্ভবত বর্ণালী হিসাবে) সংরক্ষণ করা ভাল এবং তারপরে অজগর বা ডাটাবেসের সাথে যোগাযোগ করে এমন একটি ভাষায় ডেটা বিশ্লেষণ করা ভাল। আপনার এসকিউএল-উইজার্ড না থাকলে।

Comments

আপনি হার্ড ড্রাইভ বনাম মেমরি ল্যাটেন্সি এর বিশাল পার্থক্যের উপর জোর দিয়েছিলেন তবে আপনার সংখ্যাগুলি 1000 এর একটি ফ্যাক্টর দ্বারা বন্ধ রয়েছে hard হার্ড ড্রাইভে যদি 10 মিমি এবং মেমরি 10ns এর বিলম্ব থাকে তবে ল্যাটেন্সিগুলি 1000 এর ফ্যাক্টর দ্বারা পৃথক নয় তবে একটি ফ্যাক্টর 1,000,000!

— spectre256

Answer 12

আমার কাছে এটি ব্যবহারের দৃশ্যের মতো শোনাচ্ছে যেখানে আপনি এখানে বর্ণিত হিসাবে "রিলেশনাল কলাম স্টোর" এর মতো কিছু চান ।

আমি ডিজাইনের ভুল বোঝাবুঝি করছি, তবে আপনি যদি প্রাথমিকভাবে অ্যারেগুলির একটি বড় সংগ্রহ নিয়ে কাজ করে থাকেন তবে সাধারণ সারি-ভিত্তিক টেবিলগুলিতে স্টোর করে রাখার অর্থ হ'ল প্রতিটি উপাদান একটি ফালিগুলির মতো। আপনি যদি সাধারণ পদ্ধতিতে স্লাইসগুলি দেখতে আগ্রহী হন তবে এটি বোধগম্য হয় তবে আপনি যদি একবারে পুরো কলামগুলিতে সত্যিই তাকান তবে এটি কম দক্ষ হতে পারে।

অ্যারেগুলি পুনরুদ্ধার করার সময়, কেবলমাত্র আপনার সাধারণীকরণের ফলে আপনাকে অন্য কোনও টেবিলের সাথে এটির যোগ দেওয়ার প্রয়োজন হবে না, তবে আপনি সিরিজটিকে হ্যাশের পরিবর্তে অ্যারে হিসাবে পুনরুদ্ধার করতে পারেন।

আমি সত্যিই সমস্যাটি বোঝা যাচ্ছি এবং আমি একটি নির্দিষ্ট সমাধানেরও পরামর্শ দিচ্ছি না।

এটি অন্য একটি আলোচনা যা প্রাসঙ্গিক হতে পারে, যদিও এটি সত্যিকারের বর্তমান বা প্রয়োগযোগ্য সমাধান না হলেও isn't

Answer 13

আমি আপনাকে চেষ্টা করুন এবং আপনার টেবিল বিভাজন সুপারিশ করব। আমাদের একক টেবিলে 80 মিলের বেশি সারি রয়েছে (শেয়ার বাজারের ডেটা) এবং এটিতে দ্রুত অ্যাক্সেস করতে কোনও সমস্যা নেই।

আপনি কীভাবে আপনার ডেটা অনুসন্ধান করবেন তার উপর নির্ভর করে আপনার পার্টিশনগুলি ডিজাইন করা উচিত। আমাদের ক্ষেত্রে তারিখ দ্বারা ভাল কাজ করে কারণ আমরা নির্দিষ্ট তারিখের জন্য জিজ্ঞাসা করি।

http://dev.mysql.com/doc/refman/5.1/en/partitioning-limitations.html

http://www.slideshare.net/datacharmer/mysql-partitions-tutorial

Answer 14

হ্যাঁ কিন্তু...

আমি টেবিলগুলির সাথে কাজ করেছি যার 2 বিলিয়ন সারি ছিল। তবে কেবল পিকে ব্যবহারের অনুসন্ধানগুলি দ্রুত হবে বলে আশা করা হয়েছিল।

সবচেয়ে বড় কথা, হার্ডওয়্যারটিতে মেমরির পুরো টেবিলগুলি ফিট করার জন্য পর্যাপ্ত র‍্যাম ছিল। যখন এটি একটি ইস্যুতে পরিণত হয়েছিল (তখনকার সময়ে 96৯ গিগাবাইটে সর্বাধিক) তখন প্রতিটি মেশিনে টেবিলের সেট আকার মেমরির সাথে ফিট করার জন্য যথেষ্ট পরিমাণে রেখে উল্লম্ব বিভাজনে যায়। এছাড়াও, মেশিনগুলি 10 জিবি ফাইবারের মাধ্যমে সংযুক্ত ছিল, সুতরাং নেটওয়ার্ক থ্রুটপুট কোনও সমস্যা ছিল না।

BTW। আপনার স্কিমা এমন কিছুর মতো দেখায় যা স্পর্শের run_idজন্য spectrum_idহ্যাশিং কী এবং ডেটা পয়েন্টগুলির জন্য হ্যাশিং কী হিসাবে ব্যবহার করে নোএসকিউএল সমাধানের সাথে ফিট করে ।

Answer 15

আমি আমার ব্লগে এই বিষয়টি সম্পর্কে লিখেছি: http://www.tocker.ca/2013/10/24/improving-t--formance-of-large-tables-in-MySQL.html

কিছু মূল পয়েন্ট পুনরাবৃত্তি করতে:

• বি-গাছগুলি বড় হওয়ার সাথে সাথে হ্রাস পায় এবং মেমরির সাথে খাপ খায় না (মাইএসকিউএল এখানে একা নয়)।
• InnoDB এর কিছু কার্যকারিতা বজায় রাখতে সহায়তা করার জন্য কিছু বৈশিষ্ট্য রয়েছে (বাফারিং পরিবর্তন করুন; আগে 'ইনসার্ট বাফার' নামে পরিচিত)।
• বিভাজনও সহায়তা করতে পারে।

আমার পোস্ট টিম মন্তব্যগুলিতে এর সাথে লিঙ্ক হয়েছে: http://www.tokutek.com/resources/benchmark-results/benchmark-vs-innodb-hdds/#iiBench

যা আইবিঞ্চ বেঞ্চমার্ক ব্যবহার করে 1 বিলিয়ন সারি সন্নিবেশ করানো দেখায়।