বিলিয়ন / ট্রিলিয়ন বিলিয়ন রেকর্ড সঞ্চয় করতে পারে কোন ডাটাবেস?

Question

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

{
   "tcp_flags": "0",
   "src_as": "54321",
   "nexthop": "1.2.3.4",
   "unix_secs": "1352234521",
   "src_mask": "23",
   "tos": "0",
   "prot": "6",
   "input": "105",
   "doctets": "186",
   "engine_type": "0",
   "exaddr": "2.3.4.5",
   "engine_id": "2",
   "srcaddr": "9.8.7.6",
   "dst_as": "12345",
   "unix_nsecs": "752265174",
   "sysuptime": "2943529544",
   "dst_mask": "24",
   "dstport": "80",
   "last": "2943523241",
   "srcport": "52672",
   "dpkts": "4",
   "output": "111",
   "dstaddr": "6.5.4.3",
   "first": "2943517993"
}

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

ধারণাটি হ'ল প্রায় এক মাসের ডেটা রাখা, যা হবে ~ 43.2 বিলিয়ন রেকর্ড। মোটামুটি অনুমান যে প্রতিটি রেকর্ডটিতে প্রায় 480 বাইট ডেটা থাকবে, এক মাসের মধ্যে 18.7 ডলার টেরাবাইট ডেটা হবে এবং সূচকের সাথে সম্ভবত তিনগুণ হবে। অবশেষে আমরা ট্রিলিয়ন রেকর্ড সংরক্ষণের জন্য এই সিস্টেমের সক্ষমতা বাড়িয়ে তুলতে চাই।

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

Comments

মন্তব্যগুলি বর্ধিত আলোচনার জন্য নয়; এই কথোপকথন চ্যাটে সরানো হয়েছে ।

— পল হোয়াইট

Answer 1

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

তত্ত্ব

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

অনুশীলন করা

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

আমি অ্যামাজনের পক্ষে কাজ করি না এবং HAProxy এবং উবুন্টু দলের সাথে কোনও সম্পর্ক নেই। এটি কোনও প্রকার প্রচারের চেয়ে ব্যক্তিগত মতামত।

Comments

আমি নিশ্চিত যে অত্যন্ত তুচ্ছ / অকেজো ক্ষেত্রে বাদ দিয়ে ও (1) অনুসন্ধান অসম্ভব।

— ফিটজসিম্মনস

দয়া করে কোনও অপরাধ নেবেন না, তবে এটি Google এ বলুন। ও (1) যত্নবান ডিজাইনের অধীনে পিবি স্কেলে অনুসন্ধান করা সম্ভব।

— ওলেকসেই

@ ইলেকসেই বিলিয়ন ডলার গুগল বাজেট আঁকার পক্ষে যুক্তিসঙ্গত তুলনা নয়।

— মার্ক স্টোরি-স্মিথ

আমি 3 টি পূর্ববর্তী মন্তব্যের সাথেO(1) search <=> unbounded storage space <=> unlimited supply of cash

— ypercubeᵀᴹ

ও (1) একক রেকর্ডের জন্য অনুসন্ধান লিনিয়ার হ্যাশ টেবিলের সাহায্যে করা যেতে পারে । । তবে এটি আপনাকে ধারাবাহিকভাবে অনুসন্ধানের ক্ষেত্রে (রেঞ্জের জন্য) কোনও দক্ষতা দেয় না। এর জন্য আপনার একটি বিটি্রি কাঠামোর কিছু বৈকল্পিক প্রয়োজন যা একটি আইটেমের জন্য ও (লগ এন)।

— কনসার্নড

Answer 2

যদি আমি এটি এসকিউএল সার্ভারে রাখি, আমি একটি টেবিলের মতো কিছু প্রস্তাব দেব:

CREATE TABLE tcp_traffic
(
    tcp_traffic_id bigint constraint PK_tcp_traffic primary key clustered IDENTITY(1,1)
    , tcp_flags smallint    /* at most 9 bits in TCP, so use SMALLINT */
    , src_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , netxhop bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , unix_secs bigint  
    , src_mask int      /* an assumption */
    , tos tinyint       /* values are 0-255, see RFC 791 */
    , prot tinyint      /* values are 0-255, see RFC 790 */
    , input int         /* an assumption */
    , doctets int       /* an assumption */
    , engine_type int   /* an assumption */
    , exaddr bigint     /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , engine_id int     /* an assumption */
    , srcaddr bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , dst_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , unix_nsecs bigint /* an assumption */
    , sysuptime bigint  /* an assumption */
    , dst_mask int      /* an assumption */
    , dstport smallint  /* ports can be in the range of 0 - 32767 */
    , [last] bigint     /* an assumption */
    , srcport smallint  /* ports can be in the range of 0 - 32767 */
    , dpkts int         /* an assumption */
    , output int        /* an assumption */
    , dstaddr bigint    /* use a big integer for the IP address instead of storing
                            it as dotted-decimal */
    , [first] bigint    /* an assumption */
);

এটি একক টেবিলের জন্য মোট আনুমানিক স্টোরেজ প্রয়োজনীয়তার ফলস্বরূপ, 43.2 বিলিওন রেকর্ডের জন্য আপনার 5.5 টিবি-র কোনও সূচী (আপনার নির্দিষ্ট প্রয়োজনীয়তা) ছাড়াই। এটি ডেটা নিজেই জন্য 130 বাইট হিসাবে গণনা করা হয়, ওভারহেডের সারি প্রতি 7 বাইট, এবং ওভারহেডের প্রতি পৃষ্ঠায় 96 বাইট। এসকিউএল সার্ভার 8KB পৃষ্ঠাগুলিতে ডেটা সঞ্চয় করে, প্রতি পৃষ্ঠায় 59 সারি করার অনুমতি দেয়। এটি এক মাসের ডেটার জন্য 732,203,390 পৃষ্ঠাগুলির সমান।

এসকিউএল সার্ভার 8-পৃষ্ঠার অংশগুলিতে (64৪ কেবি) ডিস্কে লেখা পছন্দ করে, যা দৈহিক I / O প্রতি 472 সারি সমান। প্রতি সেকেন্ডে 16,203 প্রবাহ রেকর্ড তৈরি হওয়ার সাথে সাথে আপনার প্রতিটি সেকেন্ডের গ্যারান্টিযুক্ত 34 আইওপিএসের ন্যূনতম I / O হারের প্রয়োজন হবে। যদিও এটি স্বয়ংক্রিয়ভাবে কোনও বিশাল পরিমাণ নয়, সিস্টেমে অন্যান্য আই / ও (এসকিউএল সার্ভার এবং অন্যথায়) কখনও এই আইওএসের প্রয়োজনীয় হারের লঙ্ঘন করে না। অতএব আপনাকে কমপক্ষে আরও একটি আইওপিএস-এর মাত্রার অর্ডার অফ আইওপিএস বা 340 টেকসই আইওএস-এর সক্ষম একটি সিস্টেম ডিজাইন করতে হবে - আমার অনুমান করতে হবে যে থ্রুপুট গ্যারান্টি দেওয়ার জন্য আপনার 2 মাত্রার আরও বেশি টেকসই IOps দরকার।

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

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

Comments

আমি সম্ভবত ব্যবহার করতে হবে binary(4)বা binary(16)যথাক্রমে। 4,000 বাইট / সারি যখন 1,000,000,000,000 দ্বারা গুণিত হয় তখন প্রচুর স্টোরেজ যুক্ত হয়।

— জন সেগেল

এবং পোর্ট সংখ্যাগুলির 0-65535 পরিসীমা রয়েছে, সুতরাং আপনি ব্যবহার করতে পারেন SMALLINTতবে সেখানেও একটি রূপান্তর রুটিন থাকতে হবে।

— ypercubeᵀᴹ

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

— স্যামস্মিথ

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

— জন সেগেল

@ মিটারেলি দুটি ব্যয় করে: ক) ডিস্ক স্টোরেজ (5-8 টিবি জন্য, সূচকগুলির দ্বারা ব্যবহৃত স্থানের উপর নির্ভর করে) খ) র‌্যাম (ক্যোয়ারিকে সমর্থন করার জন্য, সূচক ক্যাচিংয়ের জন্য)। একচেটিয়াভাবে এটি করতে সাধারণত একটি বড় RAID10 অ্যারে বা SAN দিয়ে সম্পন্ন করা হত। তবে নোট করুন যে শার্যাডিং অবশ্যই করা যায় এবং একাধিক এসকিউএল সার্ভারের উপর কাজের চাপ বাড়িয়ে দেওয়ার জন্য আপনি অ্যাপ্লিকেশন স্তরের যুক্তি ব্যবহার করতে পারেন। এটি আপনাকে প্রত্যেকটি 0.5-2tb সহ সস্তা সার্ভারগুলি ব্যবহার করার অনুমতি দিতে পারে এবং এমনকি এটি বিনামূল্যে এসকিউএল সার্ভার সংস্করণও ব্যবহার করতে পারে। (নোট করুন যে শারডিং একটি সাধারণ ধারণা, প্রায়শই অ্যাপ পর্যায়ে সম্পন্ন হয় এবং যে কোনও

— দৃ pers়তা

Answer 3

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

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

যেহেতু আপনি প্রতিটি ক্ষেত্র জুড়ে জিজ্ঞাসা করতে চান, আমি তাদের প্রত্যেকের জন্য একটি অনন্য টেবিল তৈরি করার পরামর্শ দেব। Src_address ডেটার উদাহরণ উদাহরণস্বরূপ, এমন একটি টেবিল রয়েছে:

1.2.3.4_timestamp1 : { data }
1.2.3.4_timestamp2 : { data }

সুতরাং আপনি যদি ২২.৩.৩.৪ জুড়ে সমস্ত ডেটার জন্য জিজ্ঞাসা করতে চান 27 মার্চ 12:00 পূর্বাহ্ণ থেকে মার্চ 27 12:01 এএম, আপনি নির্দিষ্ট শুরু এবং স্টোর সারি নির্দিষ্ট করে একটি পরিসীমা স্ক্যান করতে পারেন।

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

Answer 4

বলেছেন:

... আমরা এই প্রকল্পের মালিকানা সমাধান দেখার বিরোধী নই are

আমি বিবেচনা সুপারিশ আইবিএম Informix ডাটাবেসের + + TimeSeries datablade। কিছু লোক যা বলে তার বিপরীতে, ইনফর্মিক্স জীবিত এবং খুব ভাল চলছে going সর্বশেষ সংস্করণটি গত মাসে (মার্চ / 2013, সংস্করণ 12.10) প্রকাশিত হয়েছিল।

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

রেফারেন্স হিসাবে কী ব্যবহার করা যায় তা আপনি এখানে বেঞ্চমার্কের একটি পিডিএফ চেক করতে পারেন । এখানে আরও প্রযুক্তিগত উদাহরণ সহ দুটি উপস্থাপনা: ডমি গাইড এবং অন্যান্য টিপস

টাইমসারিগুলির সাথে আমার ব্যক্তিগত অভিজ্ঞতা নেই , তাই আমি সম্মতি জানাতে পারি না এটি "সমাধান" হবে, মূল্যায়নের জন্য কেবল একটি পরামর্শ।

Answer 5

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

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