খুব বড় ডাটাবেস ফাইল সহ স্ক্লাইটের পারফরম্যান্স বৈশিষ্ট্যগুলি কী কী? [বন্ধ]


325

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

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

আমি 2 গিগাবাইট থেকে মাল্টি-গিগাবাইট সীমাতে স্ক্লাইট ডাটা ফাইলগুলির বিষয়ে কথা বলছি। কারও সাথে এর কোন অভিজ্ঞতা আছে? কোন টিপস / ধারণা?


1
- থ্রেডিং (থ্রেড প্রতি সংযোগ) ব্যবহার করে শুধুমাত্র পড়ার জন্য সাহায্য করতে পারে stackoverflow.com/a/24029046/743263
malkia


23
বছর 2016: আমার কাছে একটি 5 জিবি ডাটাবেস যা এসকিউএলাইটে কোনও সমস্যা ছাড়াই চলে। আমি পোস্টগ্রিসে ঠিক একই ডেটাसेट ইনস্টল করেছি। এসকিউএলাইট ২.7 এমএসে একটি জটিল ক্যোয়ারী চালিয়েছে, 2.5 এমএসে পোস্টগ্র্যাস করেছে। সহজ রেগেক্স অ্যাক্সেস এবং আরও ভাল সূচক বৈশিষ্ট্যগুলির জন্য আমি পোস্টগ্র্রেসে শেষ হয়েছি। তবে আমি এসকিউএলাইট দ্বারা প্রভাবিত হয়েছিল এবং এটিও ব্যবহার করতে পারতাম।
পলব

উত্তর:


246

সুতরাং আমি খুব বড় ফাইলগুলির জন্য স্ক্লাইট দিয়ে কিছু পরীক্ষা করেছি এবং কিছু সিদ্ধান্তে এসেছি (কমপক্ষে আমার নির্দিষ্ট প্রয়োগের জন্য)।

পরীক্ষাগুলি একটি একক টেবিল বা একাধিক টেবিল সহ একক স্ক্লাইট ফাইল অন্তর্ভুক্ত করে। প্রতিটি টেবিলের প্রায় 8 টি কলাম, প্রায় সমস্ত পূর্ণসংখ্যা এবং 4 টি সূচক ছিল।

স্ক্লাইট ফাইলগুলি প্রায় 50 গিগাবাইট না হওয়া পর্যন্ত পর্যাপ্ত ডেটা toোকানো হবে The

একক ছক

আমি এক টেবিলের সাহায্যে একাধিক সারি একটি স্ক্লাইট ফাইলে toোকানোর চেষ্টা করেছি। ফাইলটি যখন 7 জিবি সম্পর্কে ছিল (দুঃখিত আমি সারি গণনা সম্পর্কে সুনির্দিষ্ট হতে পারি না) সন্নিবেশগুলি অনেক বেশি সময় নিচ্ছিল। আমি অনুমান করেছি যে আমার সমস্ত ডেটা myোকাতে আমার পরীক্ষায় 24 ঘন্টা বা তার বেশি সময় লাগবে, তবে এটি 48 ঘন্টা পরেও শেষ হয়নি।

এটি আমাকে এই সিদ্ধান্তে নিয়ে যায় যে একটি একক, খুব বড় স্ক্লাইট টেবিলটিতে সন্নিবেশ এবং সম্ভবত অন্যান্য ক্রিয়াকলাপগুলির সাথে সমস্যা থাকবে।

আমার ধারণা এটি আশ্চর্যের কিছু নয়, যেহেতু টেবিলটি বড় হয়, সমস্ত সূচকগুলি সন্নিবেশ করা এবং আপডেট করা আরও বেশি সময় নেয়।

একাধিক টেবিল

আমি তখন বেশিরভাগ টেবিলের উপরে ডেটা বিভক্ত করার চেষ্টা করেছিলাম, প্রতিদিন একটি টেবিল। মূল 1 টেবিলের ডেটা ~ 700 টেবিলগুলিতে বিভক্ত ছিল।

এই সেটআপটি সন্নিবেশ নিয়ে কোনও সমস্যা ছিল না, সময় বাড়ার সাথে বেশি সময় লাগেনি, যেহেতু প্রতিদিন একটি নতুন টেবিল তৈরি করা হয়েছিল।

ভ্যাকুয়াম ইস্যু

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

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

উপসংহার

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

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

আমি সম্ভবত ফাইল প্রতি টেবিল আকার নিরীক্ষণ করতে হবে তা দেখতে গতি কখন সমস্যা হয়ে উঠবে।

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


5
খুব দরকারী তথ্য। খাঁটি জল্পনা কিন্তু আমি অবাক হয়েছি যে নতুন ব্যাকআপ এপিআই আপনার ডেটাবেজের একটি নন খণ্ডিত সংস্করণটি প্রতিদিনের ভিত্তিতে তৈরি করতে এবং ভ্যাকিউম চালানোর প্রয়োজনীয়তা এড়াতে ব্যবহৃত হতে পারে কিনা।
ইডোনোহো

24
আমি কৌতূহলী, আপনার লেনদেনের সমস্ত সংজ্ঞা কি ছিল?
পল লেফেব্রে

9
হ্যাঁ, প্রতি লেনদেন 10000 বার্তার ব্যাচে সন্নিবেশ করা হয়েছিল।
স্নাজ্জার

6
আপনি কোন ফাইল সিস্টেম ব্যবহার করেছেন? যদি ext {2,3,4 ext হয়, ডেটা = সেটিংটি কী ছিল, জার্নালিং সক্ষম ছিল? আইও প্যাটার্নগুলি ছাড়াও স্ক্লাইটটি যেভাবে ডিস্কে ফ্লাশ করে তা উল্লেখযোগ্য হতে পারে।
টুবু

5
আমি মূলত উইন্ডোতে পরীক্ষা করছিলাম, তাই লিনাক্সের আচরণ সম্পর্কে মন্তব্য করতে পারি না।
স্নাজজার

169

আমরা আমাদের প্ল্যাটফর্মে 50 গিগাবাইট + ডিবিএস ব্যবহার করছি। কোন অভিযোগ দুর্দান্ত কাজ করে না। আপনি সবকিছু ঠিকঠাক করছেন তা নিশ্চিত করুন! আপনি কি পূর্বনির্ধারিত বিবৃতি ব্যবহার করছেন? * এসকিউএলটি 3.7.3

  1. লেনদেন
  2. প্রাক বিবৃতি দেওয়া
  3. এই সেটিংস প্রয়োগ করুন (আপনি ডিবি তৈরির ঠিক পরে)

    PRAGMA main.page_size = 4096;
    PRAGMA main.cache_size=10000;
    PRAGMA main.locking_mode=EXCLUSIVE;
    PRAGMA main.synchronous=NORMAL;
    PRAGMA main.journal_mode=WAL;
    PRAGMA main.cache_size=5000;

আশা করি এটি অন্যকে সহায়তা করবে, এখানে দুর্দান্ত কাজ করবে


22
160 জিবি রেঞ্জের ডিবিএস দিয়ে সম্প্রতি পরীক্ষিত, দুর্দান্ত কাজ করে।
স্নাজজার

10
এছাড়াও PRAGMA main.temp_store = MEMORY;
বিক্রান্ত চৌধুরী চৌধুরী

40
@ অ্যালেক্স, কেন দুটি PRAGMA মেইন.ক্যাস_সাইজ = 5000 ;?
জ্যাক

23
অন্ধভাবে এই অপ্টিমাইজেশান প্রয়োগ করবেন না। বিশেষত সিঙ্ক্রোনাস = সাধারণ সাধারণ ক্রাশ-নিরাপদ নয়। উদাহরণস্বরূপ, সঠিক সময়ে একটি প্রক্রিয়া ক্র্যাশ এমনকি ডিস্ক ব্যর্থতার অভাবে এমনকি আপনার ডাটাবেসকে দূষিত করতে পারে। sqlite.org/pragma.html#pragma_synchronous
MPM

22
@ অ্যালেক্স আপনি কি দয়া করে সেই মানগুলি এবং 'ডিফল্ট এবং এর মধ্যে পার্থক্যটি ব্যাখ্যা করতে পারেন?
এম

65

আমি কোনও লক্ষণীয় পারফরম্যান্স সমস্যা ছাড়াই সাইজুলাইট ডাটাবেস 3.5 গিগাবাইট পর্যন্ত তৈরি করেছি। আমি যদি সঠিকভাবে মনে রাখি তবে আমি মনে করি এসকিউএলাইট 2 এর কিছু কম সীমাবদ্ধতা থাকতে পারে তবে আমি মনে করি না এসকিউএলাইট 3 এর মতো কোনও সমস্যা আছে।

SQLite সীমা পৃষ্ঠা অনুসারে প্রতিটি ডাটাবেস পৃষ্ঠার সর্বাধিক আকার 32K। এবং একটি ডাটাবেসে সর্বাধিক পৃষ্ঠাগুলি হল 1024 ^ 3। সুতরাং আমার গণিতে যা সর্বোচ্চ আকার হিসাবে 32 টেরাবাইটে আসে। আমার মনে হয় এসকিউএলাইটের আঘাতের আগে আপনি আপনার ফাইল সিস্টেমের সীমাটি হিট করবেন!


3
8 জি স্ক্লাইট ডাটাবেসে 3000 সারি মুছে ফেলার চেষ্টা করে আপনি কী অপারেশন করছেন তার উপর নির্ভরশীল, ফরাসি প্রেসের একটি দুর্দান্ত পাত্র তৈরি করতে আপনার যথেষ্ট সময় লাগে, লোল
বেনজামিনজ

4
@ বেঞ্জামিনজ, আপনি অবশ্যই এটি ভুল করছেন। যদি আপনি একটি লেনদেনে 3 কে সারি মুছে ফেলা করেন তবে এটি প্রায় তাত্ক্ষণিক হওয়া উচিত। আমার নিজেই এই ভুল হয়েছিল: 10 কে সারি এক এক করে মুছে ফেলতে 30 মিনিট সময় লেগেছে। তবে একবার আমি সমস্ত মুছে ফেলা বিবৃতিগুলি একটি লেনদেনে মুড়ে ফেলেছিলাম, এটি 5 সেকেন্ডে নিয়েছে।
এমভিপি

55

আপনার সন্নিবেশগুলি করতে 48 ঘন্টা সময় লেগেছিল তার বেশিরভাগ কারণ হ'ল আপনার সূচী। এটি অবিশ্বাস্যভাবে দ্রুত:

1 - সমস্ত সূচক ফেলে দিন 2 - সমস্ত সন্নিবেশ করুন 3 - আবার সূচি তৈরি করুন


23
এটি সুপরিচিত ... তবে দীর্ঘ চলমান প্রক্রিয়ার জন্য আপনি আপনার সূচিগুলি পর্যায়ক্রমে পুনর্নির্মাণের জন্য রেখে যাবেন না, বিশেষত যখন আপনি তাদের কাজ করতে জিজ্ঞাসা করছেন। স্কেলাইট ডিবি যখন স্ক্র্যাচ থেকে পুনর্নির্মাণ করতে হবে, সমস্ত সন্নিবেশ সম্পন্ন হওয়ার পরে সূচীগুলি তৈরি করা হচ্ছে এটিই এমন দৃষ্টিভঙ্গি।
স্নাজজার

24
@ স্নাজের অনুরূপ পরিস্থিতিতে আমরা একটি "সংযোজক" টেবিল ব্যবহার করতাম: প্রতিদিন একবার আমরা তারপরে সঞ্চিত সারিগুলি একক লেনদেনের মধ্যে সঞ্চারকারী টেবিল থেকে মূল টেবিলের দিকে নিয়ে যেতাম। যেখানে একটি ভিউ প্রয়োজন উভয় টেবিলকে একক টেবিল হিসাবে উপস্থাপনের যত্ন নিয়েছিল।
সিএএফএক্সএক্স

4
আর একটি বিকল্প হ'ল সূচিগুলি রাখা, তবে inোকানোর আগে ডেটাটিকে সূচি-ক্রমে পূর্ব-বাছাই করা।
স্টিভেন ক্রিস্কাল্লা

1
@ স্টেভেনক্রাইস্কাল্লা কীভাবে সূচকগুলি বাদ দেওয়ার এবং তাদের পুনরায় তৈরি করার সাথে তুলনা করে? আপনি জানেন যে কোনও লিঙ্ক বেঞ্চমার্ক করেছে?
এমসিএমিলাব

1
@ এমসিএমিল্যাব এটি বহু বছর আগে ছিল তাই আমি সমস্ত বিবরণ বা মাপদণ্ডের পরিসংখ্যানের কথা মনে রাখি না, তবে স্বজ্ঞাতভাবে চিন্তা করে এনকে এলোমেলোভাবে আদেশ করা উপাদানগুলিকে একটি সূচীতে সন্নিবেশ করাতে O (NlogN) সময় লাগবে, যখন এন বাছাই করা উপাদানগুলি সন্নিবেশ করাতে O (N) লাগবে ) সময়।
স্টিভেন ক্রিস্কাল্লা

34

সাধারণ সুপারিশ ছাড়াও:

  1. বাল্ক সন্নিবেশের জন্য ড্রপ সূচক।
  2. বড় লেনদেনে ব্যাচের সন্নিবেশ / আপডেট।
  3. আপনার বাফার ক্যাশে / অক্ষম জার্নাল / ডাব্লু PRAGMAs টিউন করুন।
  4. একটি 64 বিট মেশিন ব্যবহার করুন (প্রচুর ক্যাশে to ব্যবহার করতে সক্ষম হতে)।
  5. [জুলাই ২০১৪ যোগ করা হয়েছে] একাধিক এসকিউএল কোয়েরি চালানোর পরিবর্তে সাধারণ টেবিল এক্সপ্রেশন (সিটিই) ব্যবহার করুন! এসকিউএলাইট রিলিজ প্রয়োজন 3.8.3।

SQLite3 এর সাথে আমার অভিজ্ঞতা থেকে আমি নিম্নলিখিতটি শিখেছি:

  1. সর্বাধিক speedোকানোর গতির জন্য, কোনও কলামের সীমাবদ্ধতার সাথে স্কিমা ব্যবহার করবেন না। (প্রয়োজন অনুসারে পরে টেবিল পরিবর্তন করুন আপনি বিকল্প টেবিলে সীমাবদ্ধতা যুক্ত করতে পারবেন না)।
  2. আপনার যা প্রয়োজন তা সঞ্চয় করতে আপনার স্কিমাটি অনুকূলিত করুন। কখনও কখনও এর অর্থ টেবিলগুলি ভাঙ্গা এবং / অথবা এমনকি সংযুক্ত করা / ডাটাবেসে সন্নিবেশ করার আগে আপনার ডেটা রূপান্তর করা। আইপি অ্যাড্রেসগুলি (দীর্ঘ) পূর্ণসংখ্যা হিসাবে সংরক্ষণ করা একটি দুর্দান্ত উদাহরণ।
  3. প্রতি ডিবি ফাইলের জন্য একটি টেবিল - লক যুক্তি হ্রাস করতে। ( আপনি যদি একটি একক সংযোগ অবজেক্ট রাখতে চান তবে আটকা ডেটাবেস ব্যবহার করুন ।
  4. এসকিউএলাইট একই কলামে বিভিন্ন ধরণের ডেটা সঞ্চয় করতে পারে (গতিশীল টাইপিং), এটি আপনার সুবিধার জন্য ব্যবহার করুন।

প্রশ্ন / মন্তব্য স্বাগত। ;-)


1
'প্রতি ডিবি ফাইলের জন্য একটি টেবিল' থেকে আপনি কতটা প্রভাব ফেলবেন? আকর্ষণীয় মনে হচ্ছে। আপনি কি মনে করেন যে আপনার টেবিলটিতে কেবল 3 টি টেবিল রয়েছে এবং এটি স্ক্র্যাচ থেকে তৈরি করা হয়েছে?
মার্টিন ভেলিজ

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

3
@ লেস্টার চেউং: আপনার দ্বিতীয় # 1 সম্পর্কিত: এটি ডক্স এবং ব্যক্তিগত অভিজ্ঞতা থেকে আমার বোঝার বিষয় যে আজকের দিনে, এসকিউএলাইট 3 টেবিলটি তৈরির পরে অলটার টেবিলে সীমাবদ্ধতাগুলি সমর্থন করে না। বিদ্যমান সারণী সারিগুলি থেকে বাধা যুক্ত করার বা অপসারণের একমাত্র উপায় হ'ল পছন্দসই বৈশিষ্ট্য সহ একটি নতুন টেবিল তৈরি করা এবং সমস্ত সারিগুলিতে অনুলিপি করা, যা সীমাবদ্ধতার সাথে একবার সন্নিবেশ করার চেয়ে ধীরে ধীরে কমবে বলে মনে হয়।
মম্বলসকেটস

3
@ উইডারশিন্স আপনি সম্পূর্ণরূপে সঠিক - এসকিউএলাইটের ALTER TABLE সীমাবদ্ধতা যুক্ত করার অনুমতি দেয় না। আমি জানি না আমি কী ধূমপান করছিলাম - উত্তরটি আপডেট করবে - ধন্যবাদ।
লেস্টার চেউং

এই পরামর্শগুলির কোনওটিরই হিউমোনাস এসকিউএলাইট ডিবি ফাইল ব্যবহারের সাথে কোনও সম্পর্ক নেই। এই উত্তরটি জমা দেওয়ার পরে প্রশ্নটি সম্পাদিত হয়েছিল?
এ। রাগর

9

আমি মনে করি স্ক্লাইট স্কেলিং সম্পর্কে প্রধান অভিযোগগুলি হ'ল:

  1. একক প্রক্রিয়া লিখুন।
  2. কোনও মিররিং নেই।
  3. কোন প্রতিলিপি।

9

আমার একটি 7 গিগাবাইট এসকিউএলাইট ডাটাবেস রয়েছে। একটি অভ্যন্তরীণ যোগদানের সাথে একটি নির্দিষ্ট ক্যোয়ারী সম্পাদন করতে 2.6s লাগে এটির গতি বাড়ানোর জন্য আমি সূচীগুলি যুক্ত করার চেষ্টা করেছি tried আমি কোন সূচক (এস) এ যোগ করেছি তার উপর নির্ভর করে কখনও কখনও কোয়েরি 0.1 এর নীচে চলে যায় এবং কখনও কখনও এটি ইউএসে 7 এর হিসাবে চলে যায়। আমি মনে করি আমার ক্ষেত্রে সমস্যাটি ছিল যে কোনও কলাম যদি খুব বেশি সদৃশ হয় তবে একটি সূচক যুক্ত করা কর্মক্ষমতা হ্রাস করে :(


9
কেন অনেক অনুলিপি সহ একটি কলাম কর্মক্ষমতা হ্রাস করবে (গুরুতর প্রশ্ন)?
মার্টিন ভেলিজ

6
কম cardinality সঙ্গে একটি কলাম সূচক কঠিন হল: stackoverflow.com/questions/2113181/...
metrix

9

এসকিউএল ডকুমেন্টেশনে একটি বিবৃতি ছিল যে কোনও ডাটাবেস ফাইলের ব্যবহারিক আকারের সীমা কয়েক ডজন জিবি: এস। এটি যখনই আপনি কোনও লেনদেন শুরু করেছিলেন তখন এসকিউএলাইটকে "বিট ম্যাপের একটি বিটম্যাপ বরাদ্দ" করার প্রয়োজনে হয়েছিল। ডাটাবেসে প্রতিটি এমবির জন্য 256 বাইট র‌্যামের প্রয়োজন ছিল। 50 গিগাবাইট ডিবি-ফাইল সন্নিবেশ করার জন্য একটি মোটা (2 ^ 8) * (2 ^ 10) = 2 ^ 18 = 256 মেগাবাইট র‌্যামের প্রয়োজন হবে।

তবে এসকিউএলাইটের সাম্প্রতিক সংস্করণগুলির হিসাবে এটির আর দরকার নেই। এখানে আরও পড়ুন ।


25
আমি খুব দুঃখিত যে আমাকে এটি উল্লেখ করতে হয়েছে তবে 2^18বাস্তবে এটি কেবল 256 কে।
গ্যাব্রিয়েল শ্রেইবার

7
@ গ্যাব্রিয়েলশ্রেইবার এটি এবং এটিও যে ৫০ গিগাবাইট (২ ^ ১০) এমবি নয়, এটি কেবল ১ জিবি। সুতরাং 50 জিবি ডাটাবেসের জন্য আপনার 12.5 এমবি মেমরির প্রয়োজন: (2 ^ 8) * (2 ^ 10) * 50
এলিপল্টোরাক

8

ভ্যাকুয়াম কমান্ডটি ব্যবহার করার সময় আমি বড় স্ক্লাইট ফাইলগুলির সাথে সমস্যার সম্মুখীন হয়েছি।

আমি অটো_ভ্যাকুয়াম বৈশিষ্ট্যটি এখনও চেষ্টা করি নি। যদি আপনি প্রায়শই ডেটা আপডেট এবং মুছে ফেলার আশা করেন তবে এটি দেখার মতো।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.