ارائه یک پایگاه کاربر بزرگ با داده های قابل اعتماد، سازگار و با تأخیر کم یک چالش بسیار سخت برای هر تیم پشتیبان است. در لجر، ما انتخاب استراتژیک را برای میزبانی از خدمات داده اصلی بلاک چین خود انجام دادیم. با اتکا نکردن به اشخاص ثالث، میتوانیم دادههای مشتریانمان را خودمان مدیریت کنیم و اطمینان حاصل کنیم که فرآیندهای اساسی به دستورالعملهای امنیتی ما و اهداف سطح خدمات مبتنی بر عملکرد (SLO) پایبند هستند.
اما این استراتژی مجموعه ای از چالش ها را نیز به همراه دارد.
اولین چالش ما این است که این خدمات اصلی ارائه دهنده داده را به دور از ابزارهای جذاب و درخشان noSQL منتقل کنیم. در این مقاله، من به این موضوع می پردازم که چرا این تصمیم دشوار را گرفتیم، پیچیدگی هایی که با آنها روبرو شدیم و مزایایی که به دست آوردیم.
هدف این مقاله نشان دادن جنبه های فنی است که باعث شد PostgreSQL را به عنوان لایه ذخیره سازی پایه جدید خود برای داده های بلاک چین انتخاب کنیم.
غواصی عمیق در داده های بلاک چین
داده های بلاک چین چندین ویژگی کلیدی دارند.
اول اینکه همیشه در حال رشد است و هیچ چیز از آن حذف نمی شود. با این حال، در عمل، اگرچه بیشتر یک بلاک چین تغییر ناپذیر است، جوان ترین بخش بلاک چین ممکن است به دلیل تضادهایی که باید حل شوند، تغییر کند. در واقع، از آنجایی که زنجیره یک شبکه همتا به همتا است، چندین بلوک قانونی ممکن است به طور موقت همزیستی داشته باشند. معمولاً قدیمیتر حذف میشود و در نتیجه چیزی که ما آن را سازماندهی مجدد مینامیم، میشود. به طور خلاصه، داده ها بین یک دم سرد تغییرناپذیر و یک حالت سر به ندرت در حال تغییر تقسیم می شوند.
مشکلی که ما در تلاش برای حل آن هستیم این است که در حالی که بلاک چین ها برای داشتن داده های بیزانسی مقاوم در برابر خطا عالی هستند، اما برای برش و برش آن بر روی بسیاری از محورها کارایی کمتری دارند. یعنی دریافت لیست عملیاتی که بر یک حساب کاربری تأثیر گذاشته است بسیار دشوار است. حتی دریافت موجودی حساب در یک بلاک چین مانند بیت کوین زمانی که لیست تراکنشها را ندارید یک چالش است.
برای غلبه بر این چالش ها، Ledger Explorer Services کل بلاک چین را ایندکس می کند. این یک سرویس بزرگ، حیاتی و حساس به عملکرد است که به طور کامل در Scala نوشته شده است و با استفاده از اثر گربه زمان اجرا با کارایی بالا سرعت ما در بیت کوین بیش از 10 هزار دور در ثانیه است، در حالی که تأخیر دم p95 را زیر 100 میلی ثانیه حفظ می کنیم. ما هم در حال جذب نیرو هستیم 😊.
کمی تاریخ
در ابتدای داستان ما، خیلی قبل از پیوستن من به شرکت، لایه سرویس داده لجر توسط یک پایگاه داده Neo4j تعبیه شده مدیریت میشد. هر جعبه سرویس دادههای خود را ایندکس میکرد و آن را به صورت محلی ارائه میکرد، که باعث مشکلات زیادی شد.
سازگاری دادهها بین نمونهها تضمین نشده بود، و اندازه خالص حالتی که باید نمایه شود، با استفاده از دیسک neo4j و رم، مقیاسپذیر نبود. این مشکل تنها با رشد شرکت بدتر شد و تولید نمونه های جدید را به چالشی فزاینده تبدیل کرد.
کاساندرا سپس به عنوان محرک اصلی این راهاندازی جدید انتخاب شد: این یک پایگاه داده خوشهای و مقیاسپذیر افقی است که در سمت AP قضیه CAP قرار دارد. مشکلات مربوط به اشتراک گذاری داده ها را حل می کند و اجازه می دهد تا یک جدایی واضح بین مؤلفه نمایه سازی، آگاه از بلاک چین و سرورهای API هدلس وجود داشته باشد.
اما اگر قرار نیست که هرگز از آن بخوانیم، چه فایده ای دارد که کل وضعیت تاریخی را در دسترس داشته باشیم؟
در مورد استفاده ما، داده های تاریخی خام به ندرت مورد نیاز است زیرا وضعیت حساب کاربر ما می تواند از آن جمع شود. این ما را بر آن داشت تا راه حل ذخیره سازی داده های موجود را که مبتنی بر پایگاه داده توزیع شده کاساندرا است، به چالش بکشیم.
حجم دادهای که در هر بلاک چین نیاز داریم، اگرچه در محدوده ترابایتی است، چیزی نیست که بتوان آن را «داده بزرگ» نامید. علاوه بر این، بخشی از if که برای پاسخگویی به اکثر سوالات (معروف به The hot path) استفاده می شود، حتی کوچکتر است. امروزه به راحتی می توان سرورهای سخت افزاری کالا با بیش از 16 ترابایت حافظه NVMe SSD را پیدا کرد. مقیاس عمودی یک ابزار بسیار قدرتمند است و یک پایگاه داده رابطهای نیز همینطور است.
در نهایت، مشکل اصلی ما با راهاندازی cassandra کنونی، نه مدل ذخیرهسازی بیهوده و نه استفاده از دادههای نامناسب، بلکه عدم سازگاری با توسعهدهندگان بود. ثابت شده است که توسعه یک ویژگی جدید مبتنی بر داده در Cassandra زمانبر است. ما برای پیادهسازی هر محور جدیدی که باید بر اساس آن دادهها را ارائه کنیم، تلاش کردیم.
با توجه به تخصص تیم ما در مهارت های مدل سازی داده ها و مهارت SQL، PostgreSQL و کاندیدای کامل بود این راه حل آزمایش شده در نبرد، قوی، آسان برای گسترش است، و آن را به یک انتخاب ایده آل تبدیل می کند.
چرا SQL را به NoSQL انتخاب کردیم:
- ترازها را می خواند / می نویسد: مورد استفاده از دادههای بلاک چین بهشدت بهجای نوشتن روی خواندنها منحرف شده است (بلاک چین دادههای بسیار کمی را با نرخ بسیار معقول مینویسد، حتی برای بلاکچینی مانند Polygon). کاساندرا توانایی جذب حجم بسیار بالایی از نوشته ها را دارد - مسیر خواندن در واقع این است دیگر از مسیر نوشتن
- پشتیبانی از نمایه سازی: شاخصها جزء کلیدی یک DBMS برای پاسخگویی به پرسشها و موارد یا فرصتهای تجاری جدید هستند. کاساندرا پشتیبانی محدودی برای نمایه سازی دارد. شاخصها تنها زمانی مؤثر هستند که کوئری از قبل راهی برای محدود کردن پارتیشنی که پرس و جو روی آن اجرا میشود مشخص کرده باشد. ما اینجا هزینه ی داشتن را می پردازیم خودسرانه توزیع شده است پایگاه داده پشتیبانی PostgreSQL برای شاخص ها کارآمد، قابل توسعه و در لبه است.
- پشتیبانی از تجمع: مورد مشابه برای تجمع; از آنجایی که Cassandra اجازه تجمع چند پارتیشنی را نمی دهد و هیچ بند GROUP BY را در زبان پرس و جو خود تحمل نمی کند، پشتیبانی آن به نوعی کم است. PostgreSQL پشتیبانی گسترده ای از تجمع را پیشنهاد می کند، حتی در انواع داده های عجیب و غریب مانند محدوده ها و حباب های jsonb.
- مدل سازی داده ها: کاساندرا در روش امکان مدلسازی دادهها بسیار بسیار محدود است. تقریباً برای هر درخواستی که میخواهید به آن پاسخ دهید باید یک جدول ایجاد شود و دادهها باید به ردیفهای بزرگ غیرعادی شوند (به طور کامل با استفاده از فروشگاه ستون عریض جنبه C* و همچنین این واقعیت که نویسنده ها ارزان هستند). PostgreSQL به ما اجازه می دهد تا از جنبه رابطه ای بلاک چین (تماس ها، تراکنش ها، بلوک ها) و فضای خالی دیسک استفاده کنیم و استفاده مجدد از داده ها را تشویق کنیم.
- پرس و جو و ممیزی موقت: توانایی استفاده از استاندارد کامل SQL و انجام پرس و جوهای دلخواه به این معنی است که می توانیم علت اصلی باگ احتمالی را کاوش و جستجو کنیم یا داده های اکتشافی برای موارد استفاده آینده داشته باشیم. ما واقعاً می توانیم از پایگاه داده به عنوان یک ابزار تعاملی و هوشمند به جای یک ذخیره سازی گنگ استفاده کنیم. انجام این کار در Cassandra بدون یک خوشه محاسباتی تحلیلی گسترده و پرهزینه مانند Presto، Spark و غیره (و از آنجایی که ما روی سرورهای فلزی خالی کار می کنیم، به ابزارهای تجزیه و تحلیل داده های توزیع شده به راحتی تولید شده مانند EMR دسترسی نداریم).
- استفاده از ذخیره سازی: فرض کاساندرا این است که ذخیره سازی بسیار ارزان است و این خوشه را می توان به راحتی با ماشین های جدید گسترش داد. یعنی همین تمام محدودیت ها در هر دو شاخص و تجمیع باید با ذخیره سازی پرداخت شود. عدم وجود شاخص های کارآمد جهانی و پشتیبانی پیوستن به این معنی است که ما باید یک کپی از کل جدول را برای هر محوری که می خواهیم پرس و جو کنیم، غیرعادی کرده و ذخیره کنیم. PostgreSQL ما را از ذخیره سازی ترابایت صرفه جویی می کند.
- ثبات: از آنجایی که Cassandra یک پایگاه داده توزیعشده و مبتنی بر AP است (ارتباط با شایعات بین گرهها ایجاد میشود)، سازگاری فقط از نظر نوشتن نهایی است. شما می توانید خط مشی سازگاری هر عبارت را هم برای خواندن و هم برای نوشتن تنظیم کنید، اما هدف این پایگاه داده هرگز این نبود که سازگاری قوی داشته باشد. PostgreSQL داستان قوی ای در مورد استفاده برای ماموریت های حیاتی دارد و بسیار انعطاف پذیر است. متمرکز بودن همچنین به این معنی است که هیچ شبکه ای در مسیر نوشتن وجود ندارد.
- معاملات و MVCC:
- معاملات: کاساندرا پشتیبانی می کند فقط معاملات سبک وزن در پرس و جوهای DML مقداری بچینگ را می توان اعمال کرد (توضیحات) اما اخطارهای زیادی وجود دارد، یعنی اینکه ردیف ها باید در یک سرور (= پارتیشن) باشند تا عملکرد وحشتناکی نداشته باشند.
- MVCC: Cassandra از علامت گذاری زمان ردیف پشتیبانی می کند اما MVCC کامل تضمین نمی شود. فشردهسازی میتواند دادههای قدیمی را پاک کند و هیچ راهی وجود ندارد که به C* بگوییم نباید این کار را انجام دهد (مانند تراکنش در PG).
- PostgreSQL از یک مدل MVCC قوی پشتیبانی می کند که مسیر خواندن یکنواخت را برای کاربران ما تضمین می کند.
- تجهیز: PostgreSQL ابزارهای بسیار بیشتری دارد که به طور گسترده برای کارکرد آسان پایگاه داده استفاده می شود. علاوه بر این، ابزاری مانند مسیر پرواز تضمین می کند که ما یک نسخه قوی از طرح پایگاه داده را حفظ می کنیم. ما قبلاً آن را با پایه کد خود با موفقیت ادغام کردیم. هیچ معادلی با این سطح از بلوغ در کاساندرا وجود ندارد.
- مقیاس پذیری افقی: این نقطه کلیدی فروش Cassandra است. فقط با گسترش داده های خود ماشین های بیشتری اضافه کنید. هیچ معادلی برای PostgreSQL به عنوان اشتراک گذاری و پارتیشن بندی نباید به صورت دستی ساخته شود.
چگونه برای مقیاس بندی برنامه ریزی می کنیم
همانطور که دیدیم، تنها نقطه ضعف استفاده از راهاندازی Postgres مقیاسپذیری در خواندن و ذخیرهسازی است. برای غلبه بر این محدودیت چه کنیم؟
اولین ابزار موثری که در اختیار داریم این است که هر پروتکل یا بلاک چینی را که پشتیبانی می کنیم در پایگاه داده خودش تفکیک کنیم، زیرا می توان با توجه به حجم و ترافیک به طور مناسب مقیاس بندی کرد. تقسیم بندی بر اساس دامنه کسب و کار، اولین لایه مقیاس بندی را تضمین می کند.
با برداشت بیشتر این مفهوم، میتوانیم دادههای سرد و تاریخی را به پارتیشن زمانی تقسیم کنیم. آخرین نسخه های Postgres قابلیت استفاده از جداول پارتیشن بندی شده را بسیار بهبود بخشیده است، که می تواند داده ها را به طور یکپارچه در میان مجموعه ای از ماشین ها جابجا کند. به عنوان مثال، ما میتوانیم از ماشینهای ارزانتر با قدرت محاسباتی کمتر برای میزبانی اکثر دادههای تاریخی استفاده کنیم، در حالی که غولهای رم پشتهای را برای میزبانی جدولهای جمعآوریشده و آخرین عملیات کاربر حفظ کنیم.
این رویکرد در مورد استفاده ما بسیار خوب عمل می کند زیرا هیچ کلید خارجی متقاطع در ذخیره سازی تاریخی وجود ندارد (همه چیز در نهایت به بلوک متصل می شود). از منظر سرور اصلی، حتی میتوان با استفاده از پارتیشنبندی و پسوند postgres_fdw به دادههای تاریخی دسترسی داشت.
به منظور کمک به قرار دادن همه این موارد، افزونه TimescaleDB را نیز بررسی کرده ایم. این برنامه افزودنی قابلیتهای زیادی را به postgres پایه اضافه میکند، و بیشتر آنها برای موارد استفاده ما مناسب هستند:
- پارتیشن بندی خودکار جداول بر اساس زمان مانند ستون (در مورد ما، با در نظر گرفتن ارتفاع بلاک چین به عنوان مرجع، آن را تطبیق می دهیم).
- فشردهسازی خودکار، آگاه از نوع داده و فشردهسازی ستونهای تکههای قدیمیتر. این امر یک نسبت فشرده سازی تقریباً کامل را با استفاده از الگوریتم های پیشرفته روی داده هایی که بسیار مشابه هستند تضمین می کند.
- تجمیع کارآمد بر اساس سطل زمان برای محاسبه آسان ترازهای تاریخی و نمودارهای داده های بازار.
ما تازه در آغاز آزمایش در مورد ذخیره سازی هستیم، و این قفل بسیاری از موارد استفاده را باز می کند. اثبات مفاهیم با استفاده از مقدار کمی داده (حدود 10 هزار بلوک در شبکه اصلی اتریوم، بنابراین حدود 2 روز داده) کاهش فضای دیسک را تا 40٪ نشان داد.
همانطور که دیدیم، حجم داده، به شرط استفاده از استراتژی مناسب، مشکلی نیست. اما چگونه با اندازه پایگاه کاربر خود مقیاس کنیم؟
ما قبلاً یک مزیت خوب در اینجا داریم: کل داده های بلاک چین را ایندکس می کنیم. بنابراین، فضای ذخیره سازی مورد نیاز نه مانند تعداد کاربران، بلکه مانند اندازه کل بلاک چین افزایش می یابد. بهینهسازیهای ذخیرهسازی و خواندن از نظر وضوح کاملاً متعامد هستند.
این راهاندازی، همراه با نیاز بسیار کم به نوشتن متناسب با حجم خواندنی که باید ارائه شود، راهاندازی رویایی برای الگوی کپی رهبر-پیرو طبقهبندی است. به منظور افزایش عملکرد و توان عملیاتی بیشتر، ما همچنین میتوانیم نسخههای خواندنی postgres را روی همان ماشینهایی قرار دهیم که سرورهای API هستند و از سوکتهای دامنه یونیکس برای پرش از رفتوآمدهای شبکه استفاده کنیم.
در اینجا مثالی از یک استراتژی تکرار داده است که میتوانیم از آن برای مقیاسبندی خواندههایمان استفاده کنیم. جعبه های خاکستری روشن نشان دهنده سرورهای منفرد هستند. در اینجا میتوانیم ببینیم که غلافهای API مستقیماً با کپیهایی از داغترین دادهها قرار گرفتهاند تا از حداقل زمان انتقال بین ذخیرهسازی و کاربران اطمینان حاصل کنند. نمونههای بایگانی که قبلاً شرح داده شدهاند، نمایش داده نمیشوند تا طرحواره را بیش از حد پیچیده نکنند.
اظهارات نهایی
به عنوان یک کاربر طولانی مدت Cassandra، می خواهم تأکید کنم که این پایگاه داده ای عالی در طراحی خود است که برای طیف گسترده ای از برنامه ها مناسب است. متأسفانه، انتخابی که در Ledger برای استفاده از آن انجام شد، روی یک مورد استفاده از داده بود که هرگز محقق نشد.
بهرهوری تیم ما تحتتاثیر قرار گرفت و به دنبال چالشهایی که باید حل کنیم، تصمیم گرفتیم گلوله را گاز بگیریم و گرفتار اشتباه هزینه غرق نشدیم.
در بسیاری از موارد، داده های شما کلان داده نیستند. مدیریت توزیع داده ها در بیشتر موارد کار دشواری نیست و معاوضه های یک پایگاه داده توزیع شده کامل واقعاً باید به دقت در نظر گرفته شود. نکته کلیدی تجربه توسعه دهنده است زیرا زمان ارزشمندی را برای ساخت هر چیز دیگری آزاد می کند. این مورد استفاده واقعی است که ما باید روی آن سرمایه گذاری زیادی داشته باشیم.
- محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
- PlatoAiStream. Web3 Data Intelligence دانش تقویت شده دسترسی به اینجا.
- ضرب کردن آینده با آدرین اشلی. دسترسی به اینجا.
- خرید و فروش سهام در شرکت های PRE-IPO با PREIPO®. دسترسی به اینجا.
- منبع: https://www.ledger.com/blog/serving-web3-at-web2-scale
- : دارد
- :است
- :نه
- $UP
- 10
- 10K
- 20
- a
- توانایی
- قادر
- دسترسی
- قابل دسترسی است
- حساب
- در میان
- واقعا
- وفق دادن
- اضافه کردن
- می افزاید:
- پایبند بودن
- مزیت - فایده - سود - منفعت
- تجمع
- الگوریتم
- معرفی
- اجازه دادن
- اجازه می دهد تا
- قبلا
- همچنین
- هر چند
- مقدار
- an
- تحلیل
- علم تجزیه و تحلیل
- و
- پاسخ
- هر
- هر چیزی
- API
- برنامه های کاربردی
- اعمال می شود
- روش
- به درستی
- بایگانی
- هستند
- دور و بر
- هنر
- مقاله
- AS
- ظاهر
- جنبه
- فرض
- At
- در دسترس
- مطلع
- دور
- تبرها
- محور
- بخش مدیریت
- برج میزان
- تعادل
- پایه
- مستقر
- خط مقدم
- BE
- زیرا
- بوده
- قبل از
- شروع
- غول ها
- بودن
- مزایای
- میان
- بزرگ
- بزرگ داده
- بیت
- بیت کوین
- مسدود کردن
- بلاکچین
- داده های blockchain
- blockchains
- بلاک ها
- هر دو
- جعبه
- جعبه
- به ارمغان می آورد
- اشکال
- ساختن
- کسب و کار
- اما
- by
- صدا
- تماس ها
- CAN
- نامزد
- کلاه لبه دار
- Осторожно
- مورد
- موارد
- علت
- ایجاد می شود
- متمرکز
- زنجیر
- به چالش
- چالش ها
- به چالش کشیدن
- تغییر دادن
- متغیر
- ارزان
- ارزان تر
- ماشین آلات ارزان تر
- انتخاب
- را انتخاب کنید
- را انتخاب
- برگزیده
- واضح
- خوشه
- رمز
- پایه کد
- سرد
- ستون
- ترکیب شده
- کالا
- ارتباط
- شرکت
- پیچیدگی ها
- جزء
- محاسبه
- مفهوم
- مفاهیم
- توجه
- در نظر گرفته
- استوار
- سرد
- هسته
- هزینه
- میتوانست
- ایجاد شده
- بحرانی
- جاری
- داده ها
- تحلیل داده ها
- به اشتراک گذاری داده ها
- ذخیره سازی داده ها
- پایگاه داده
- روز
- تصمیم
- شرح داده شده
- طرح
- توسعه دهنده
- در حال توسعه
- مشکل
- مستقیما
- خاک
- توزیع شده
- توزیع
- تقسیم شده
- do
- میکند
- عمل
- دامنه
- آیا
- نزولی
- رویا
- راننده
- دو
- e
- هر
- به آسانی
- ساده
- لبه
- موثر
- موثر
- دیگر
- جاسازی شده
- اهمیت دادن
- قادر ساختن
- دلگرم کننده
- بالا بردن
- اطمینان حاصل شود
- تضمین می کند
- حصول اطمینان از
- معادل
- و غیره
- ethereum
- شبکه برق اتریوم
- حتی
- سرانجام
- تا کنون
- هر
- همه چیز
- مثال
- موجود
- عجیب و غریب
- گسترش می یابد
- تجربه
- تخصص
- اکتشاف
- جستجوگر
- گسترش
- گسترش
- وسیع
- واقعیت
- سقوط
- ویژگی
- امکانات
- کمی از
- پیدا کردن
- نام خانوادگی
- مناسب
- برای
- خارجی
- به جلو
- دوستی
- از جانب
- کامل
- تمام عیار
- کاملا
- ویژگی های
- بیشتر
- آینده
- گرفتن
- داده
- در سطح جهانی
- هدف
- رفتن
- نمودار ها
- خاکستری
- بزرگ
- گروه
- شدن
- در حال رشد
- تضمین شده
- دستورالعمل ها
- بود
- سخت
- سخت افزار
- آیا
- داشتن
- سر
- به شدت
- ارتفاع
- کمک
- اینجا کلیک نمایید
- زیاد
- خیلی
- تاریخی
- میزبان
- HOT
- داغترین
- چگونه
- چگونه
- اما
- HTML
- HTTPS
- i
- دلخواه
- if
- تغییر ناپذیر
- نهفته
- اجرای
- بهبود یافته
- in
- به طور فزاینده
- شاخص
- Indices
- نمونه
- یکپارچه
- تعاملی
- به
- سرمایه گذاری
- گرفتار
- موضوع
- مسائل
- IT
- ITS
- پیوستن
- پیوست
- JPG
- تنها
- نگهداری
- کلید
- کلید
- نوع
- عدم
- زبان
- بزرگ
- تاخیر
- آخرین
- لایه
- رهبری
- دفتر کل
- قانونی
- کمتر
- سطح
- قدرت نفوذ
- سبک
- سبک وزن
- پسندیدن
- محدودیت
- محدودیت
- محدود شده
- فهرست
- کوچک
- به صورت محلی
- طولانی
- نگاه
- به دنبال
- خیلی
- کم
- ماشین آلات
- ساخته
- اصلی
- mainnet
- حفظ
- اکثریت
- ساخت
- مدیریت
- مدیریت
- دستی
- بسیاری
- بازار
- اطلاعات بازار
- بلوغ
- حداکثر عرض
- ممکن است..
- به معنی
- فلز
- مهاجرت
- حداقل
- ماموریت
- مدل
- مدل سازی
- بیش
- علاوه بر این
- اکثر
- حرکت
- بسیار
- باید
- از جمله
- تقریبا
- نیاز
- ضروری
- نیازهای
- نه
- شبکه
- هرگز
- جدید
- خوب
- نه
- گره
- هیچ چی
- عدد
- متعدد
- اهداف
- of
- on
- ONE
- فقط
- کار
- عملیات
- فرصت ها
- or
- سفارش
- ما
- خودمان
- روی
- غلبه بر
- خود
- پرداخت
- بخش
- احزاب
- مسیر
- الگو
- پرداخت
- همکار
- همکار برای همکار
- کامل
- کارایی
- چشم انداز
- محل
- برنامه
- افلاطون
- هوش داده افلاطون
- PlatoData
- غلاف
- نقطه
- سیاست
- چند ضلعی
- ممکن
- postgresql
- پتانسیل
- قدرت
- قوی
- تمرین
- مشکل
- فرآیندهای
- بهره وری
- اثبات
- نسبت
- پیشنهاد می کند
- پروتکل
- اثبات شده
- ارائه
- ارائه
- قرار دادن
- نمایش ها
- رم
- محدوده
- نرخ
- نسبتا
- نسبت
- خام
- خواندن
- واقعی
- واقعا
- معقول
- کاهش
- با توجه
- مربوط
- قابل اعتماد
- سازماندهی مجدد
- پاسخ
- تکرار
- نشان دادن
- نمایندگی
- درخواست
- انعطاف پذیر
- وضوح
- مصمم
- نتیجه
- استفاده مجدد
- راست
- تنومند
- ریشه
- دور
- ROW
- دویدن
- در حال اجرا
- همان
- اسکالا
- مقیاس پذیر
- مقیاس
- مقیاس گذاری
- یکپارچه
- جستجو
- تیم امنیت لاتاری
- دیدن
- مشاهده گردید
- بخش
- تقسیم بندی
- فروش
- نقطه فروش
- سرویس
- خدمات
- خدمت
- تنظیم
- برپایی
- چند
- sharding
- اشتراک
- کوتاه
- نشان
- طرف
- مشابه
- پس از
- تنها
- اندازه
- مهارت ها
- کوچک
- کوچکتر
- هوشمند
- So
- راه حل
- حل
- حل می کند
- برخی از
- فضا
- جرقه
- تخم ریزی
- SQL
- استاندارد
- دولت
- بیانیه
- ذخیره سازی
- opbevare
- داستان
- استراتژیک
- استراتژی
- قوی
- به شدت
- موفقیت
- پشتیبانی
- پشتیبانی از
- جدول
- گرفتن
- مصرف
- کار
- تیم
- فنی
- گفتن
- قوانین و مقررات
- نسبت به
- که
- La
- بلوک
- دولت
- شان
- سپس
- آنجا.
- اینها
- آنها
- سوم
- اشخاص ثالث
- این
- توان
- زمان
- به
- هم
- ابزار
- ابزار
- جمع
- کاملا
- ترافیک
- معامله
- معاملات
- انتقال
- شفاف
- نوع
- انواع
- در نهایت
- زیر
- اساسی
- متاسفانه
- یونیکس
- باز کردن
- بدون نیاز
- us
- قابلیت استفاده
- استفاده
- استفاده کنید
- مورد استفاده
- استفاده
- کاربر
- کاربران
- با استفاده از
- معمولا
- ارزشمند
- تنوع
- عمودی
- بسیار
- حجم
- می خواهم
- بود
- مسیر..
- we
- Web2
- Web3
- خوب
- چی
- چه شده است
- چه زمانی
- که
- در حین
- در حالیکه
- تمام
- چرا
- وسیع
- به طور گسترده ای
- اراده
- با
- بدون
- با این نسخهها کار
- نوشتن
- کتبی
- شما
- جوانترین
- شما
- زفیرنت