ফাইল সিস্টেমে এক মিলিয়ন চিত্র সংরক্ষণ করা

79

আমার একটি প্রকল্প রয়েছে যা বিপুল সংখ্যক চিত্র তৈরি করবে। প্রায় 1,000,000 শুরু করার জন্য। এগুলি বড় ইমেজ নয় তাই শুরুতে আমি এগুলি সমস্ত একটি মেশিনে রেখে দেব।

আপনি কীভাবে এই চিত্রগুলি দক্ষতার সাথে সঞ্চয় করার পরামর্শ দিচ্ছেন? (এনটিএফএস ফাইল সিস্টেম বর্তমানে)

আমি একটি নামকরণের স্কিমটি বিবেচনা করছি ... শুরু করার জন্য সমস্ত চিত্রের 1 থেকে এক বর্ধনশীল নাম থাকবে আমি আশা করি এটি প্রয়োজনে পরে এগুলি সাজানোর জন্য এবং বিভিন্ন ফোল্ডারে ফেলে দিতে সহায়তা করবে hope

এর চেয়ে ভাল নামকরণের স্কিমটি কী হবে:

a / b / c / 0 ... z / z / z / 999

অথবা

এ / বি / সি / 000 ... জেড / জেড / জেড / 999

এ সম্পর্কে কোন ধারণা?

storage  ntfs  images 
— s.mihai
সূত্র
1
তারা নির্দিষ্ট ব্যবহারকারীদের সাথে আবদ্ধ বা কেবল জেনেরিক? তারা কোন ফ্যাশনে গ্রুপ করা হয়?
শুধুমাত্র জেনেরিক কিছু প্রযুক্তিগত সরঞ্জাম দ্বারা উত্পাদিত ইচ্ছার গুচ্ছ। একটি সময় পুনঃস্থাপনের ধারণা পেতে আমি তাদের 1 থেকে বর্ধনশীল নামকরণ করছি।
— s.mihai
তারা কীভাবে ব্যবহার / অ্যাক্সেস হতে চলেছে? একটি bespoke অ্যাপ্লিকেশন মাধ্যমে বা কি?
— কবুতর
16
এটা তুমি? i46.tinypic.com/1z55k7q.jpg
1
:)) হ্যাঁ ... 1 মিলি। অশ্লীল চিত্র :))
— s.mihai

উত্তর:

73

আমি ডাটাবেসের পরিবর্তে একটি নিয়মিত ফাইল সিস্টেম ব্যবহার করার পরামর্শ দেব। ডাটাবেসের চেয়ে ফাইল সিস্টেম ব্যবহার করা সহজ, আপনি ফাইলগুলি অ্যাক্সেসের জন্য সাধারণ সরঞ্জামগুলি ব্যবহার করতে পারেন, ফাইল সিস্টেমগুলি এই ধরণের ব্যবহারের জন্য নকশাকৃত etc.

ডাটাবেসের আসল পাথ সংরক্ষণ করবেন না। চিত্রের সিকোয়েন্স নম্বরটি ডাটাবেসে সংরক্ষণ করা এবং ফাংশন থাকা সিকোয়েন্স নম্বর থেকে পথ তৈরি করা ভাল। উদাহরণ:

 File path = generatePathFromSequenceNumber(sequenceNumber);

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

আমি ডিরেক্টরি কাঠামো তৈরির জন্য এই ধরণের অ্যালগরিদম ব্যবহার করব:

  1. আপনার কমপক্ষে 12 ডিজিটের স্ট্রিং না হওয়া পর্যন্ত প্রথম প্যাডগুলি শীর্ষস্থানীয় জিরোগুলির সাথে সিকোয়েন্স নম্বর। এটি আপনার ফাইলের নাম। আপনি একটি প্রত্যয় যুক্ত করতে চাইতে পারেন:
    • 12345 -> 000000012345.jpg
  2. তারপরে স্ট্রিংটিকে 2 বা 3 টি অক্ষরের ব্লকে বিভক্ত করুন যেখানে প্রতিটি ব্লক একটি ডিরেক্টরি স্তরকে চিহ্নিত করে। ডিরেক্টরি স্তরের একটি নির্দিষ্ট সংখ্যা রয়েছে (উদাহরণস্বরূপ 3):
    • 000000012345 -> 000/000/012
  3. উত্পন্ন ডিরেক্টরিতে ফাইল সংরক্ষণ করুন:
    • এভাবে ক্রম আইডি সহ ফাইলের জন্য সম্পূর্ণ পাথ ও ফাইলের ফাইলের নাম 123হল 000/000/012/00000000012345.jpg
    • সিকোয়েন্স আইডি সহ ফাইলের জন্য 12345678901234পথটি হবে123/456/789/12345678901234.jpg

ডিরেক্টরি কাঠামো এবং ফাইল স্টোরেজ সম্পর্কে কিছু বিষয় বিবেচনা করতে হবে:

  • উপরের অ্যালগরিদম আপনাকে এমন একটি সিস্টেম দেয় যেখানে প্রতিটি লিফ ডিরেক্টরিতে সর্বাধিক 1000 টি ফাইল থাকে (যদি আপনার কাছে 1 000 000 000 000 ফাইলের পরিমাণ কম থাকে)
  • ডিরেক্টরিতে কতগুলি ফাইল এবং উপ-ডিরেক্টরি থাকতে পারে তার সীমাবদ্ধতা থাকতে পারে, উদাহরণস্বরূপ , লিনাক্সের এক্সট 3 ফাইল সিস্টেমের প্রতিটি ডিরেক্টরিতে 31998 উপ-ডিরেক্টরিগুলির সীমা রয়েছে।
  • সাধারণ সরঞ্জাম (উইনজিপ, উইন্ডোজ এক্সপ্লোরার, কমান্ড লাইন, ব্যাশ শেল, ইত্যাদি) খুব ভাল কাজ করতে পারে না যদি আপনার প্রতি ডিরেক্টরিতে বড় সংখ্যক ফাইল থাকে (> 1000)
  • ডিরেক্টরি কাঠামো নিজেই কিছু ডিস্কের জায়গা নেবে, সুতরাং আপনি খুব বেশি ডিরেক্টরি চাইবেন না।
  • উপরের কাঠামোর সাহায্যে আপনি সর্বদা চিত্রের নামটি দেখে চিত্র ফাইলের জন্য সঠিক পথটি সন্ধান করতে পারেন, যদি আপনি আপনার ডিরেক্টরি স্ট্রাকচারগুলিতে গোলযোগ সৃষ্টি করেন।
  • আপনার যদি বেশ কয়েকটি মেশিন থেকে ফাইল অ্যাক্সেস করতে হয় তবে একটি ফাইল ফাইল সিস্টেমের মাধ্যমে ফাইলগুলি ভাগ করে নেওয়ার বিষয়টি বিবেচনা করুন।
  • আপনি প্রচুর ফাইল মুছলে উপরের ডিরেক্টরি কাঠামোটি কাজ করবে না। এটি ডিরেক্টরি কাঠামোতে "গর্ত" ছেড়ে দেয়। তবে যেহেতু আপনি কোনও ফাইল মুছছেন না তা ঠিক হওয়া উচিত।
— জুহা সিরিজালি
সূত্র
1
অনেক আগ্রহব্যাঞ্জক! ফাইলের নাম বিভক্ত করা হচ্ছে ... আমি এটা ভেবে দেখিনি। আমি ধরে নিই এটি এটি করার মার্জিত উপায়: -?
— s.mihai
37
ফাইলের নাম হিসাবে হ্যাশ (যেমন MD5) ব্যবহারের পাশাপাশি ডিরেক্টরি বিতরণ কাজ করবে। ফাইলগুলির অখণ্ডতা কেবলমাত্র নামকরণের স্কিমের (পাশাপাশি পরীক্ষা করা) এক পক্ষের উপকারী হবে না, তবে আপনার পুরো ডিরেক্টরি বিকাশ জুড়ে যুক্তিযুক্ত এমনকি বিতরণও হবে। সুতরাং আপনার কাছে যদি "f6a5b1236dbba1647257cc4646308326.jpg" নামে একটি ফাইল থাকে তবে আপনি এটিকে "/ f / 6" (অথবা আপনার প্রয়োজন মতো গভীর) এ সঞ্চয় করতে পারেন। 2 স্তরের গভীর 256 ডিরেক্টরি দেয় বা প্রাথমিক 1 মি ফাইলের জন্য কেবল 4000 ফাইলের অধীনে ডিরেক্টরি দেয়। একটি গভীর স্কিমে পুনঃভাগ বিতরণ স্বয়ংক্রিয় করা খুব সহজ হবে।
+1 আমি সবেমাত্র লক্ষ্য করেছি যে এই উত্তরটি আমি সবেমাত্র পোস্ট করেছি to
— 3dinfluence
1
আমি অবশ্যই ফাইলসিসটেমটি ব্যবহার করে এবং ফোল্ডারের নামগুলিতে "স্লাইস" করতে একটি আর্টফিকিয়াল আইডেন্টিফায়ার তৈরির বিষয়ে সম্মত। তবে আপনার শনাক্তকারীদের এলোমেলো বিতরণ করার চেষ্টা করা উচিত, অর্থাৎ সিকোয়েন্স নম্বরটি ব্যবহার করবেন না। এটি আপনাকে ফোল্ডারের আরও সুষম গাছ রাখতে দেয়। এ ছাড়াও এলোমেলো বিতরণের মাধ্যমে আপনি আরও সহজেই একাধিক ফাইল সিস্টেম জুড়ে গাছটিকে ভাগ করতে পারেন। আমি ডিপআপ চালু এবং একটি ফাইল সিস্টেমের জন্য একটি স্পারস ভলিউমযুক্ত একটি জেডএফএস ভিত্তিক এসএএনও ব্যবহার করব। আপনি সান অ্যাক্সেস করতে iSCSI ব্যবহার করে এখনও এনটিএফএস ব্যবহার করতে পারেন।
— মাইকেল ডিলন
আপনি যদি দ্বিতীয় ধাপে ডান থেকে বামে যান তবে ফাইলগুলি সমানভাবে বিতরণ করা হয়। এছাড়াও আপনি চিন্তা করতে হবে না যে আপনি সীমাহীন সংখ্যক ফাইল করতে পারেন হিসাবে আপনি পর্যাপ্ত শূন্যগুলি পূরণ করছেন না
— রোপো
31

আমি আমার 2 সেন্ট মূল্য রাখতে যাচ্ছি এক ধরণের নেতিবাচক পরামর্শের জন্য: কোনও ডাটাবেস নিয়ে যাবেন না।

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

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

— Satanicpuppy
সূত্র
হ্যাঁ. নোট নেওয়া!
— s.mihai
5
আপনি কি এসকিউএল ২০০৮ এর ফাইলস্ট্রেম ডেটা টাইপটি দেখেছেন? এটি ডাটাবেস এবং ফাইল সিস্টেম স্টোরেজের মধ্যে একটি ক্রস।
— নোটমে
আপনি দ্রুত এবং খুব কম আইও ক্রিয়াকলাপ করছেন কারণ ডাটাবেসের চেয়ে ফাইল সার্ভারের সাথে লেগে থাকা +1 ic
আপনি যদি কেবল ডাটাবেস প্রতি কয়েকশ ডক্স বা ছবি তোলা - স্টোরেজ জন্য ডেটাবেস ব্যবহার করার কোন খারাপ দিক?
— বিপ বীপ
1
+1 ... একটি ফাইল সিস্টেম কোনও উপায়ে একটি "ডাটাবেস" (নিশ্চিতভাবে এনটিএফএস), তাই কেন এটি অতিরিক্ত জটিল করে তুলুন।
— আকির
12

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

সুতরাং বলুন যে আপনার কাছে এমন একটি ফাইলের একটি হ্যাশ রয়েছে যা 515d7eab9c29349e0cde90381ee8f810
আপনি নিম্নলিখিত স্থানটিতে এটি সংরক্ষণ করতে পারেন এবং প্রতিটি ফোল্ডারে ফাইলের সংখ্যা কম রাখার জন্য আপনার কত স্তরের গভীরতা প্রয়োজন তা আপনি ব্যবহার করতে পারেন।
\51\5d\7e\ab\9c\29\349e0cde90381ee8f810.jpg

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

— 3dinfluence
সূত্র
2
গিট একই ধরণের পদ্ধতির ব্যবহার করে: git-scm.com/book/en/v2/Git-Internals- গিট- ওবজেক্টস (এই উত্তরটি ব্যাক আপ করতে)
— এক্সেল
11

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

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

যেমন,

/ রুট / [0-99] / [0-99] / ফাইলের নাম

দ্রষ্টব্য, http://technet.microsoft.com/en-us/library/cc781134(WS.10).aspx এ এনটিএফএস সেটআপ সম্পর্কে আরও বিশদ রয়েছে। বিশেষত, "আপনি যদি এনটিএফএস ফোল্ডারে (300,000 বা তার বেশি) বড় সংখ্যক ফাইল ব্যবহার করেন তবে ভাল পারফরম্যান্সের জন্য শর্ট-ফাইলের নাম উত্পাদন নিষ্ক্রিয় করুন, এবং বিশেষত যদি দীর্ঘ ফাইলের নামের প্রথম ছয় অক্ষর একই হয়।"

আপনার প্রয়োজন নেই এমন ফাইল-সিস্টেম বৈশিষ্ট্যগুলি অক্ষম করার বিষয়টিও দেখতে হবে (যেমন, শেষ অ্যাক্সেসের সময়)। http://www.pctools.com/guides/registry/detail/50/

— জেসন ইয়ানোভিটস
সূত্র
3
8.3 ফাইলের নাম উত্পাদন এবং শেষ অ্যাক্সেসের সময় অক্ষম করার জন্য +1; আমি যখন "বিশাল সংখ্যক [ফাইল]" এবং "এনটিএফএস" (উইন্ডোজ) পড়ি তখন এটিই প্রথম মনে হয়েছিল।
— ডাব
লিঙ্ক ডাউন ........................
— পেসারিয়ার
7

আপনি যা করেন না কেন, সেগুলি একটি ডিরেক্টরিতে সংরক্ষণ করবেন না।

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

তাই:

ফোল্ডারটিতে img\a\b\c\d\e\f\g\'abcdefg' এবং আরও কিছু দিয়ে শুরু হওয়া চিত্র থাকবে।

আপনি আপনার নিজের যথাযথ গভীরতার পরিচয় দিতে পারেন।

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

— উইম হলব্র্যান্ডস
সূত্র
now a \ b this c \ d \ e \ f \ আমি এখনই করছি, আমি ভাবছিলাম এটি করার কোনও বুদ্ধিমান উপায় আছে।
— s.mihai
1
এগুলি কীভাবে শারীরিকভাবে সংরক্ষণ করা যায় তার একটি সাধারণভাবে গৃহীত সমাধান। স্পষ্টতই চিত্রটির URL তৈরি করা এমন কিছু যা সহজেই চিত্র ফাইলের নামের উপর ভিত্তি করে গতিময়ভাবে করা যায়। এছাড়াও, তাদের পরিবেশন করার জন্য, আপনি লোডিংয়ের সময়ের গতি বাড়ানোর জন্য চিত্রগুলি সার্ভারে img-a, img-b সাবডোমেনগুলি এমনকি পরিচয় করিয়ে দিতে পারেন।
2
এবং "সেগুলিকে একটি ডিরেক্টরিতে সংরক্ষণ করবেন না" এর জন্য +1। আমি এমন একটি উত্তরাধিকার ব্যবস্থাটি সমর্থন করছি যা একক ফোল্ডারে একটি সার্ভারে 47000 ফাইল রেখেছিল এবং এক্সপ্লোরারটিকে কেবল ফোল্ডারটি খুলতে প্রায় এক মিনিট সময় লাগে।
— মার্ক র্যানসোম
5
\ B \ c \ d \ e \ f \ g করার ফলে ডিরেক্টরি কাঠামো খুব গভীর হয় এবং প্রতিটি ডিরেক্টরিতে কেবল কয়েকটি ফাইল থাকে। ডিরেক্টরি স্তরের প্রতি একটি অক্ষরের বেশি ব্যবহার করা ভাল ab উদাহরণস্বরূপ ab \ cd \ ef \ বা abc \ def \ \ ডিরেক্টরিগুলি ডিস্ক থেকে স্থানও নেয় তাই আপনি এগুলির মধ্যে অনেকগুলি না চান।
— জুহা সিরাজিলা
2
আমাকে এমন একটি অ্যাপ্লিকেশন সমর্থন করতে হয়েছিল যাতে সমস্ত ডিরেক্টরিতে 4 + মিলিয়ন ফাইল থাকে; এটি আশ্চর্যজনকভাবে ভালভাবে কাজ করেছে, তবে আপনি ফোল্ডারটি খোলার জন্য এক্সপ্লোরারকে কখনই পেতে পারেন না, এটি ক্রমাগতভাবে নতুন সংযোজনগুলি বাছাই করে। এনটিএফএস মরতে না পারলে এটি পরিচালনা করতে সক্ষম হওয়ার জন্য +1।
— SqlACID
5

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

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

— Lukasz
সূত্র
চিত্রগুলি ঘন ঘন অ্যাক্সেসের জন্য বোঝানো হয় না। সুতরাং এটি নিয়ে কোনও সমস্যা নেই। তাদের সংখ্যা বেশ দ্রুত বাড়বে। আমি ধরে নিলাম সেখানে 1 মিলি থাকবে 1 মাসে চিহ্নিত করুন।
— s.mihai
আমি প্রোগ্রামার ভিউতে আগ্রহী তাই যাতে আমি এটিকে খুব বেশি ভাবি না
— s.mihai
সুতরাং আপনার যদি দ্রুত অ্যাক্সেসের প্রয়োজন না হয় তবে হ্যাস্ট্যাক সম্ভবত আপনার পক্ষে নয়। পার্টিশনের জন্য ডিরেক্টরি ব্যবহার করা আমার দৃষ্টিতে সহজ সমাধান।
— লুকাশজ
5

4 মিলিয়ন ইমেজ সহ আমাদের একটি ফটো স্টোর সিস্টেম রয়েছে। আমরা কেবল মেটা ডেটার জন্য ডেটাবেস ব্যবহার করি এবং সমস্ত চিত্র একটি উল্টো নামকরণ সিস্টেম ব্যবহার করে ফাইল সিস্টেমে সঞ্চিত হয়, যেখানে ফোল্ডারের নামগুলি ফাইলের শেষ সংখ্যা, শেষ -1 ইত্যাদি থেকে উত্পন্ন হয়। যেমন: 000001234.jpg ডিরেক্টরি কাঠামোতে 4 \ 3 \ 2 \ 1 \ 000001234.jpg এর মতো সঞ্চয় করা হয়।

এই স্কিমটি ডাটাবেসে পরিচয় সূচকে খুব ভালভাবে কাজ করে, কারণ এটি সমানভাবে পুরো ডিরেক্টরি কাঠামো পূরণ করে।

4

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

— মিঃ বয়
সূত্র
: -? ভাল দ্রুত পয়েন্ট। কেবল এখন আমার কাছে পথ তৈরির জন্য অ্যালগরিদম নেই।
— s.mihai
4

নতুন এমএস এসকিউএল ২০০৮ এ এই জাতীয় কেসগুলি পরিচালনা করার জন্য একটি নতুন বৈশিষ্ট্য রয়েছে, এটিকে ফাইলস্ট্রেম বলা হয়। এক নজর দেখে নাও:

মাইক্রোসফ্ট টেকনেট ফাইলস্ট্রেম ওভারভিউ

— পদু মেরলোতি
সূত্র
4

আপনার চিত্রগুলি কি অনন্যভাবে নামকরণ করা দরকার? এই চিত্রগুলি উত্পন্ন করার প্রক্রিয়াটি একই ফাইল নামটি একাধিকবার তৈরি করতে পারে? কোন ডিভাইসটি ফাইলের নামটি তৈরি করছে তা না জেনে বলা শক্ত কিন্তু বলা উচিত যে ডিভাইসটি 'রিসেট' এবং পুনরায় চালু হওয়ার সাথে সাথে চিত্রগুলির নামকরণ শুরু হয় কারণ এটি শেষবারের মতো 'রিসেট' হয়েছিল - যদি এটি এমন উদ্বেগ থাকে তবে ..

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

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

imgs\yyyy\mm\filename.ext

where: yyyy = 4 digit year
         mm = 2 digit month

example:  D:\imgs\2009\12\aaa0001.jpg
          D:\imgs\2009\12\aaa0002.jpg
          D:\imgs\2009\12\aaa0003.jpg
          D:\imgs\2009\12\aaa0004.jpg
                   |
          D:\imgs\2009\12\zzz9982.jpg
          D:\imgs\2010\01\aaa0001.jpg (this is why I ask about uniqueness)
          D:\imgs\2010\01\aab0001.jpg

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

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

আমি / উত্তর দেওয়ার সময় আপনি / অন্যরা এই ধারণাগুলি সম্বোধন করতে পারেন .. আশা করি এটি সহায়তা করে ..

— Taptronic
সূত্র
1. সমস্ত ফাইলের নামকরণ করা হবে অনন্য ly 2. প্রথমে সিস্টেমটি বৃদ্ধি এবং বৃদ্ধি পাবে এটি 1 মিলিল চিত্রের চারপাশে বের হবে এবং তারপরে প্রতি মাসে কয়েক হাজার দশকের হারে বৃদ্ধি পাবে। 3. ভবিষ্যতে কোন এক সময় ফাইলগুলির মধ্যে কিছু প্রকারের ট্যাগিং থাকবে, সে কারণেই আমি ডিবিতে কিছু ধরণের সনাক্তকরণ তথ্য সংরক্ষণ করতে চাই।
— s.mihai
3

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

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

একটি দিনের চেয়ে পুরানো চিত্রগুলি একটি "দৈনিক" জিপতে একত্রিত হয়; এক মাসের চেয়ে পুরানো জিপগুলি তাদের নিজ নিজ "মাসিক" জিপগুলিতে একত্রিত করা হয়; এবং অবশেষে এক বছরেরও বেশি কিছু করার দরকার নেই এবং ফলস্বরূপ মুছে ফেলা হবে।

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

আমি বুঝতে পারি এটি সম্ভবত আপনার বিশেষ বিবরণের সাথে সম্পর্কিত নয় তবে আমি ভেবেছিলাম আমি ভাগ করে নেব।

— JYelton
সূত্র
2

সম্ভবত কোনও তৈরির তারিখ ভিত্তিক নামকরণ প্রকল্প - ফাইলের নামের সমস্ত তথ্য সহ বা (পরে ব্রাউজ করার জন্য ভাল) এটি ডিরেক্টরিতে বিভক্ত করা। আপনি কতবার চিত্র তৈরি করেন তার উপর নির্ভর করে আমি নিম্নলিখিতগুলি সম্পর্কে ভাবতে পারি:

  • প্রতিদিন বেশ কয়েকটি চিত্র উত্পন্ন হয়: Year/Month/Day/Hour_Minute_Second.png
  • এক মাস কয়েক: Year/Month/Day_Hour_Minute_Second.png

ইত্যাদি আপনি আমার বক্তব্য পেয়েছেন ... =)

— টমাস আসচান
সূত্র
এগুলি অবিচ্ছিন্নভাবে সময়ের সাথে উত্পন্ন হয় না, তাই কিছু ফোল্ডারগুলি মোটা হয়ে যায় এবং অন্যরা ... স্লিম :))
— s.mihai
ঠিক আছে, আপনাকে অবশ্যই প্রতিটি ফোল্ডার তৈরি করতে হবে না , কারণ আপনি এই স্কিমটি অনুসরণ করছেন। এমনকি আপনি থাকতেও পারেন Year/Month/Day/Hour/Minute- হার সর্বাধিক হলে চিত্রগুলি কতবার উত্পন্ন হয় তার উপর নির্ভর করে আপনার কত স্তরের ফোল্ডার দরকার তা - এবং তারপরে খালি রেখে যাওয়া ফোল্ডারগুলি তৈরি করবেন না।
— টমাস আসচান
2

আমি একটি তারিখ ভিত্তিক ফোল্ডার কাঠামো তৈরি করতে আগ্রহী হব, যেমন \ বছর \ মাস \ দিন, এবং ফাইলের নামগুলির জন্য টাইমস্ট্যাম্প ব্যবহার করি। প্রয়োজনবোধে, চিত্রগুলি এত দ্রুত তৈরি করতে গেলে টাইমস্ট্যাম্পগুলিতে একটি অতিরিক্ত কাউন্টার উপাদান থাকতে পারে যাতে মিলিসেকেন্ডের মধ্যে একের বেশি থাকতে পারে। নামকরণ বাছাইয়ের জন্য সর্বাধিক উল্লেখযোগ্য থেকে কমপক্ষে উল্লেখযোগ্য ক্রম ব্যবহার করে সন্ধান এবং রক্ষণাবেক্ষণ একটি বাতাস। যেমন hhmmssmm [seq] .jpg

— জন গার্ডেনিয়ার্স
সূত্র
2

আপনি কি দুর্যোগ পুনরুদ্ধার বিবেচনা করছেন?

এখানে প্রস্তাবিত কিছু সমাধান ফাইলের নাম ম্যাঙ্গেলিংয়ের অবসান ঘটিয়েছে (যেমন যদি দৈহিক ফাইলটি সরানো হয় তবে এটি আসলে কী ফাইলের ট্র্যাকটি হারাবেন)। আমি একটি অনন্য শারীরিক ফাইলের নাম বজায় রাখার পরামর্শ দিচ্ছি যাতে আপনার ফাইলের অবস্থানের মাস্টার তালিকাটি দূষিত হয়ে যায়, আপনি এটি একটি ছোট শেল, এর, পাওয়ারশেল, স্ক্রিপ্ট দিয়ে পুনরায় জেনারেট করতে পারেন;)

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

মেশিন বা ফাইল সিস্টেমের মধ্যে ফাইল স্থানান্তর করতে আপনাকে কী ধরণের পদ্ধতি তৈরি করতে হবে তা বিবেচনা করুন। আপনার সিস্টেমের সাথে এটি করার ক্ষমতাটি লাইভ এবং অনলাইনে আপনাকে রাস্তার নিচে যথেষ্ট মাথা ব্যথা বাঁচাতে পারে।

আপনার বর্ধিত নম্বর কাউন্টার (ডাটাবেস সনাক্তকরণ কলাম?) গণ্ডগোল হয়ে যাওয়ার ক্ষেত্রে আপনি একটি বর্ধিত সংখ্যার পরিবর্তে একটি জিআইইডি একটি দৈহিক ফাইল নাম হিসাবে বিবেচনা করতে পারেন।

উপযুক্ত হলে, সিডিএন যেমন অ্যামাজন এস 3 ব্যবহার করে বিবেচনা করুন।

— ডোনাল্ড বাইার্ড
সূত্র
2

যদিও আমি সেই স্কেলে ছবি পরিবেশন করি নি, আমি এর আগে একটি 400MHz মেশিনে 25k ডলার ছবি সরবরাহের জন্য একটি ছোট গ্যালারী অ্যাপ লিখেছি। 512 এমবি র‌্যাম বা তারও বেশি। কিছু অভিজ্ঞতা;

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

  • ফাইল সিস্টেমটি কী আচরণ করে তা গবেষণা করুন; ext3- এ (বা এটি তখন ext2 ছিল - মনে করতে পারে না), সাব-ডিরেক্টরি এবং ফাইলগুলি দক্ষতার সাথে সন্ধান করতে সক্ষম হবার সীমাটি 256 এর কাছাকাছি ছিল; সুতরাং যে কোনও ফোল্ডারে কেবলমাত্র এতগুলি ফাইল এবং ফোল্ডার রয়েছে। আবার লক্ষণীয় স্পিডআপ। যদিও আমি এনটিএফএস সম্পর্কে জানি না, এক্সএফএসের মতো স্টাফ (যা বি-ট্রি ব্যবহার করে, যতদূর আমার মনে আছে) অত্যন্ত দ্রুত, কেবলমাত্র তারা খুব দ্রুত অনুসন্ধান করতে পারে বলেই।

  • সমানভাবে ডেটা বিতরণ; যখন আমি উপরের সাথে পরীক্ষা-নিরীক্ষা করেছি, আমি সমস্ত ডিরেক্টরিতে ডেটা সমানভাবে বিতরণের চেষ্টা করেছি (আমি ইউআরএলটির একটি এমডি 5 করেছি এবং এটি ডিরেক্টরিতে ব্যবহার করেছি; /1a/2b/1a2b...f.jpg)। এইভাবে পারফরম্যান্সের যে কোনও সীমা রয়েছে তা হিট করতে বেশি সময় লাগে (এবং ফাইল সিস্টেম ক্যাশে এত বড় ডেটাসেটগুলিতে যাইহোক বাতিল)। (বিপরীতে, আপনি সীমাটি প্রথম দিকে কোথায় শুরু হয়েছে তা দেখতে চাইতে পারেন; তারপরে আপনি প্রথম উপলভ্য ডিরেক্টরিতে সমস্ত কিছু ফেলে দিতে চান)।

— মর্টেন সিবুহর
সূত্র
2

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

String fileName = "cat.gif";
int hash = fileName.hashCode();
int mask = 255;
int firstDir = hash & mask;
int secondDir = (hash >> 8) & mask;

এর ফলে পথটি সৃজনশীল হবে:

/172/029/cat.gif

এরপরে আপনি cat.gifঅ্যালগরিদম পুনরুত্পাদন করে ডিরেক্টরি কাঠামোতে সন্ধান করতে পারেন ।

ডিরেক্টরিটির নাম হিসাবে HEX ব্যবহার করা intমানকে রূপান্তর করার মতো সহজ হবে :

String path = new StringBuilder(File.separator)
        .append(String.format("%02x", firstDir))
        .append(File.separator)
        .append(String.format("%02x", secondDir)
        .toString();

ফলাফল এতে:

/AC/1D/cat.gif

আমি কয়েক বছর আগে এ সম্পর্কে একটি নিবন্ধ লিখেছিলাম এবং সম্প্রতি এটি মিডিয়ামে স্থানান্তরিত করেছি। এটিতে আরও কয়েকটি বিশদ এবং কিছু নমুনা কোড রয়েছে: ফাইলের নাম হ্যাশিং: একটি হাশড ডিরেক্টরি কাঠামো তৈরি করা । আশাকরি এটা সাহায্য করবে!

— মাইকেল অ্যান্ড্রুজ
সূত্র
আমরা অনুরূপ কিছু ব্যবহার করে 1.8 বিলিয়ন আইটেম সঞ্চয় করি। এটা ভাল কাজ করে. একটি হ্যাশ ব্যবহার করুন যা দ্রুত এবং কম সংঘর্ষের হার রয়েছে এবং আপনি সেট হয়ে গেছেন।
— সিভিভিএস
1

যদি তাদের সমস্ত তাত্ক্ষণিকভাবে প্রয়োজন হয় না এবং আপনি সেগুলি অন-ফ্লাই তৈরি করতে পারেন এবং এগুলি ছোট চিত্র, তবে আপনার চিত্র জেনারেটরের উপরে এলআরইউ মেমরি- বা ডিস্ক-ক্যাশে প্রয়োগ করবেন না কেন?

এটি আপনাকে স্টোরেজ থেকে বাঁচাতে এবং মেমো থেকে পরিবেশন করার জন্য গরম চিত্রগুলি রাখতে পারে?

— জে কিউ
সূত্র
1

আমি কেবল জেডএফএসের উপর একটি পরীক্ষা চালিয়েছি কারণ আমি জেডএফএসকে ভালবাসি, এবং আমার একটি 500gig পার্টিশন ছিল যা আমার সংকোচনে ছিল। আমি একটি স্ক্রিপ্ট লিখেছিলাম যা 50-100k ফাইল উত্পন্ন করে এগুলিকে 1/2/3/4/5/6/7/8 (5-8 স্তর গভীর) ডিরেক্টরিতে রেখেছিল এবং এটি 1 সপ্তাহ ধরে চালানোর অনুমতি দেয়। (এটি কোনও দুর্দান্ত স্ক্রিপ্ট ছিল না)) এটি ডিস্কটি পূর্ণ করেছে এবং প্রায় 25 মিলিয়ন ফাইল বা তারও বেশি শেষ হয়েছে। পরিচিত পথ সহ যে কোনও একটি ফাইলে অ্যাক্সেস তাত্ক্ষণিক ছিল। কোনও পরিচিত পাথের সাথে কোনও ডিরেক্টরি তালিকাভুক্ত করা তাত্ক্ষণিক ছিল।

ফাইলগুলির তালিকার একটি গণনা পাওয়া (অনুসন্ধানের মাধ্যমে) 68৮ ঘন্টা সময় নিয়েছে।

আমি একটি ডিরেক্টরিতে অনেকগুলি ফাইল রেখে একটি পরীক্ষাও চালিয়েছি। আমি থামার আগে একটি ডিরেক্টরিতে প্রায় 3.7 মিলিয়ন ফাইল পেয়েছিলাম। একটি কাউন্ট পেতে ডিরেক্টরিটি তালিকাভুক্ত হতে প্রায় 5 মিনিট সময় নেয়। ডিরেক্টরিতে সমস্ত ফাইল মুছতে 20 ঘন্টা সময় নেয়। তবে কোনও ফাইলের সন্ধান এবং অ্যাক্সেস তাত্ক্ষণিক ছিল।

— স্টু
সূত্র
1

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

আপনি নিম্নলিখিত স্পেসিফিকেশন দ্বারা আগ্রহী হতে পারেন, বেশিরভাগ ডিজিটাল ক্যামেরা ফাইল স্টোরেজ পরিচালনা করতে এটি অনুসরণ করে: https://en.wikedia.org/wiki/Camera_I छवि_File_ Format

মূলত, একটি ফোল্ডার তৈরি করা হয়, যেমন 000OLYMPUSএবং ফোল্ডারগুলি সেই ফোল্ডারে যুক্ত করা হয় (উদাহরণস্বরূপ DSC0000.RAW)। যখন ফাইল নেম কাউন্টারে পৌঁছে যায় তখন DSC9999.RAWএকটি নতুন ফোল্ডার তৈরি হয় ( 001OLYMPUS) এবং চিত্রটি আবার যুক্ত করা হয়, কাউন্টারটিকে পুনরায় সেট করে, সম্ভবত কোনও পৃথক উপসর্গ (উদাহরণ P_0000.RAW:) দিয়ে।

বিকল্পভাবে আপনি ফাইলের নামের অংশগুলির উপর ভিত্তি করে ফোল্ডারও তৈরি করতে পারেন (ইতিমধ্যে বেশ কয়েকবার উল্লেখ করেছেন)। উদাহরণস্বরূপ, যদি আপনার ফটোটির নাম দেওয়া হয় তবে IMG_A83743.JPGএটিকে সংরক্ষণ করুন IMG_\A8\3\IMG_A83743.JPG। এটি প্রয়োগ করা আরও জটিল তবে আপনার ফাইলগুলি সন্ধান করা আরও সহজ করে দেবে।

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

— রল্ফ
সূত্র
0

আপনি জেডএফএস (ফাইল সিস্টেম, সান থেকে ভলিউম ম্যানেজার) সম্মানের দিকে নজর রাখতে চাইতে পারেন

0

একটি বৃহত সংখ্যক থেকে পথ উত্পন্ন করার একটি পরিষ্কার উপায় হ'ল এটিকে সহজেই হেক্সে রূপান্তর করা হয় তারপরে এটি বিভক্ত করুন!

উদাহরণস্বরূপ 1099496034834> 0xFFFF1212>FF/FF/12/12

public string GeneratePath(long val)
{  
    string hex = val.ToString("X");
    hex=hex.PadLeft(10, '0');
    string path="";
    for(int i=0; i<hex.Length; i+=2 )
    {
        path += hex.Substring(i,2);
        if(i+2<hex.Length)
            path+="/";
    }
    return path;
}

স্টোর এবং লোড:

public long Store(Stream doc)
{
   var newId = getNewId();
   var fullpath = GeneratePath(newId)
   // store into fullpath 
   return newId;
}

public Stream Load(long id)
{
   var fullpath = GeneratePath(newId)
   var stream = ... 
   return stream;
}

সম্পূর্ণ উত্স কোড: https://github.com/acrobit/AroroFS

— Ghominejad
সূত্র
-1

দুর্ভাগ্যক্রমে ফাইল সিস্টেমগুলি খুব খারাপ (প্রচুর ছোট ফাইল পরিচালনা করার ক্ষেত্রে ডিরেক্টরি প্রতি ডিরেক্টরি বা গভীর ডিরেক্টরি গাছের সাথে পারফরম্যান্স, পুনরায় চালু করার সময় পরীক্ষা করা, নির্ভরযোগ্যতা) তাই আপনি যদি ফাইল সিস্টেমটি ব্যবহার করতে চান তবে উপরের সমাধানটি জিপ ফাইলগুলির সাথে জড়িত best

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

-2

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

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

— jdmichal
সূত্র
5
সেখানে এসেছেন, এটি করেছেন, এটি প্রমাণ করার জন্য চিহ্ন রয়েছে। ডেটাবেসগুলি যেগুলি প্রচুর পরিমাণে চিত্রগুলি সঞ্চয় করে তা বিশ্বাসের বাইরে প্রায় আঁকাবাঁকা এবং এর জন্য প্রচুর পরিমাণে রক্ষণাবেক্ষণের প্রয়োজন হয়। ফাইল সিস্টেমে এগুলি সংরক্ষণ করা আরও ভাল যদি আপনার কোনও নির্দিষ্ট প্রয়োজন না থাকে যার উত্তর কেবলমাত্র একটি ডাটাবেস দ্বারা দেওয়া যেতে পারে (আমাদের সংস্করণ ট্র্যাকিং ছিল))
— শয়তানিকপ্পি
1
এবং ফাইল এবং ফাইল সিস্টেমের সাথে ডিল করার জন্য প্রচুর ইউটিলিটি রয়েছে, একটি ডাটাবেসের মধ্যে ফাইলগুলির সাথে কারও কারও কাছে যোগাযোগ নেই।
— মার্ক রান্সম
2
ওহ Godশ্বর না, দয়া করে বৃহত্তর BLOB সঞ্চয়স্থান হিসাবে একটি ডাটাবেস ব্যবহার করবেন না।
— নীল এন
Eek। জানতেন না যে ডাটাবেসগুলিতে (এখনও?) বিএলএবগুলি নিয়ে এতগুলি সমস্যা রয়েছে।
এতগুলি মন্তব্যে এমন একটি খারাপ সমাধানের কীভাবে এখনও একটি +1 থাকতে পারে? ওপিকে কোনও অপরাধ নেই (আমি দেখতে পাচ্ছি এটি এসও থেকে এসেছে) তবে ডাউনভোট বোতামটি এখানে একটি কারণে রয়েছে!
— মার্ক হেন্ডারসন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.