27 KiB
| machine_translated | machine_translated_rev | toc_priority | toc_title |
|---|---|---|---|
| true | d734a8e46d |
69 | نحوه اجرای تست های کلیک خانه |
تست کلیک
تست های کاربردی
تست های کاربردی ساده ترین و راحت برای استفاده هستند. بسیاری از clickhouse ویژگی ها را می توان مورد آزمایش با استفاده از آزمون های عملکردی و آنها را اجباری به استفاده از برای هر تغییر در clickhouse کد است که می تواند آزمایش می شود که در راه است.
هر تست عملکردی یک یا چند نمایش داده شد به سرور در حال اجرا تاتر می فرستد و نتیجه را با مرجع مقایسه می کند.
تست ها در واقع queries فهرست راهنما. دو زیرشاخه وجود دارد: stateless و stateful. تست های بدون تابعیت بدون هیچ گونه داده های تست پیش بارگذاری شده نمایش داده می شوند-اغلب مجموعه داده های مصنوعی کوچک را در پرواز در داخل تست خود ایجاد می کنند. تست های نفرت انگیز نیاز به داده های تست از قبل نصب شده از یاندکس.متریکا و در دسترس عموم نیست. ما تمایل به استفاده از تنها stateless تست ها و جلوگیری از اضافه کردن جدید stateful تستها
هر تست می تواند یکی از دو نوع باشد: .sql و .sh. .sql تست اسکریپت ساده مربع است که به لوله کشی است clickhouse-client --multiquery --testmode. .sh تست یک اسکریپت است که به خودی خود اجرا است.
برای اجرای تمام تست ها استفاده کنید testskhouse-test ابزار. نگاه کن --help برای لیستی از گزینه های ممکن. شما به سادگی می توانید تمام تست ها را اجرا کنید یا زیر مجموعه ای از تست های فیلتر شده توسط زیر رشته را در نام تست اجرا کنید: ./clickhouse-test substring.
ساده ترین راه برای فراخوانی تست های کاربردی کپی است clickhouse-client به /usr/bin/ فرار کن clickhouse-server و سپس اجرا کنید ./clickhouse-test از دایرکتوری خود را.
برای اضافه کردن تست جدید, ایجاد یک .sql یا .sh پرونده در queries/0_stateless فهرست راهنما را به صورت دستی بررسی کنید و سپس تولید کنید .reference پرونده به روش زیر: clickhouse-client -n --testmode < 00000_test.sql > 00000_test.reference یا ./00000_test.sh > ./00000_test.reference.
تست باید استفاده کنید (ساختن, قطره, و غیره) تنها جداول در test پایگاه داده است که فرض بر این است که از قبل ایجاد می شود; همچنین تست می توانید جداول موقت استفاده.
اگر شما می خواهید به استفاده از نمایش داده شد توزیع شده در تست های کاربردی, شما می توانید اهرم remote تابع جدول با 127.0.0.{1..2} یا شما می توانید خوشه تست از پیش تعریف شده در فایل پیکربندی سرور مانند استفاده کنید test_shard_localhost.
برخی از تست ها با مشخص شده اند zookeeper, shard یا long در نام خود را.
zookeeper برای تست هایی است که از باغ وحش استفاده می کنند. shard برای تست هایی است که
نیاز به سرور برای گوش دادن 127.0.0.*; distributed یا global همان
معنی. long برای تست هایی است که کمی طولانی تر اجرا می شوند که یک ثانیه. شما می توانید
غیر فعال کردن این گروه از تست با استفاده از --no-zookeeper, --no-shard و
--no-long گزینه, به ترتیب.
اشکالات شناخته شده
اگر ما می دانیم برخی از اشکالات است که می تواند به راحتی توسط تست های کاربردی تکثیر, ما تست های عملکردی تهیه شده در queries/bugs فهرست راهنما. این تست خواهد شد به نقل مکان کرد teststests_stateless هنگامی که اشکالات ثابت هستند.
تست های ادغام
ادغام آزمون اجازه می دهد برای تست clickhouse در خوشه پیکربندی و clickhouse تعامل با سرور های دیگر مانند mysql, postgres, mongodb. مفید برای تقلید انشعابات شبکه قطره بسته و غیره هستند. این تست ها تحت کارگر بارانداز اجرا و ایجاد ظروف متعدد با نرم افزار های مختلف.
ببینید testsgration/README.md در مورد چگونگی اجرای این تست.
توجه داشته باشید که ادغام کلیک با رانندگان شخص ثالث تست نشده است. همچنین ما در حال حاضر تست های یکپارچه سازی با رانندگان جی بی سی و بی سی ما ندارد.
واحد آزمون
تست واحد مفید هستند که شما می خواهید برای تست نیست خانه کلیک به عنوان یک کل, اما یک کتابخانه جدا شده و یا کلاس. شما می توانید ساخت تست ها را فعال یا غیر فعال کنید ENABLE_TESTS گزینه کیک. تست واحد (و دیگر برنامه های تست) در واقع tests زیرشاخه در سراسر کد. برای اجرای تست واحد, نوع ninja test. برخی از تست ها استفاده می کنند gtest, اما برخی فقط برنامه هایی که بازگشت کد خروج غیر صفر در شکست تست.
این لزوما به واحد آزمون اگر این کد در حال حاضر تحت پوشش تست عملکرد (و آزمون عملکردی معمولا بسیار ساده تر برای استفاده).
تست های عملکرد
تست های عملکرد اجازه می دهد برای اندازه گیری و مقایسه عملکرد برخی از بخش جدا شده از خانه رعیتی در نمایش داده شد مصنوعی. تست ها در واقع tests/performance. هر تست توسط نمایندگی .xml فایل با شرح مورد تست. تست ها با اجرا clickhouse performance-test ابزار (که در تعبیه شده است clickhouse دودویی). ببینید --help برای نیایش.
هر تست یک یا چند ضلعی نمایش داده شد (احتمالا با ترکیبی از پارامترهای) در یک حلقه با برخی از شرایط برای توقف (مانند “maximum execution speed is not changing in three seconds”) و اندازه گیری برخی از معیارهای مورد عملکرد پرس و جو (مانند “maximum execution speed”). برخی از تست ها می توانند پیش شرط ها را در مجموعه داده های تست پیش بارگذاری شده داشته باشند.
اگر شما می خواهید برای بهبود عملکرد تاتر در برخی از سناریو, و اگر پیشرفت را می توان در نمایش داده شد ساده مشاهده, بسیار توصیه می شود برای نوشتن یک تست عملکرد. همیشه حس می کند به استفاده از perf top و یا دیگر ابزار دقیق در طول تست های خود را.
ابزار تست و اسکریپت
برخی از برنامه ها در tests دایرکتوری آماده نیست اما در حال تست ابزار. برای مثال برای Lexer یک ابزار وجود دارد dbms/Parsers/tests/lexer این فقط تقلید از استدین را انجام می دهد و نتیجه رنگی را به انحراف می نویسد. شما می توانید از این نوع ابزار به عنوان نمونه کد و برای اکتشاف و تست دستی استفاده کنید.
شما همچنین می توانید جفت فایل قرار دهید .sh و .reference همراه با ابزار برای اجرا در برخی از ورودی از پیش تعریف شده - سپس نتیجه اسکریپت را می توان به مقایسه .reference پرونده. این نوع تست ها خودکار نیستند.
تست های متنوعات
تست برای لغت نامه های خارجی واقع در وجود دارد tests/external_dictionaries و برای مدل های ماشین یاد گرفته شده در tests/external_models. این تست ها به روز نمی شوند و باید به تست های ادغام منتقل شوند.
تست جداگانه برای درج حد نصاب وجود دارد. این اجرای آزمون clickhouse خوشه در سرورهای جداگانه و شبیه سازی شکست های مختلف در موارد: شبکه تقسیم بسته رها کردن (بین clickhouse گره بین clickhouse و باغ وحش بین clickhouse سرور و کلاینت ، ), kill -9, kill -STOP و kill -CONT مثل جپسن. سپس چک تست که همه درج اذعان نوشته شده بود و همه درج رد شد.
تست حد نصاب توسط تیم جداگانه نوشته شده بود قبل از کلیک باز منابع بود. این تیم دیگر با کلیکهاوس کار. تست تصادفی در جاوا نوشته شده بود. به این دلایل, تست حد نصاب باید بازنویسی شود و به تست ادغام نقل مکان کرد.
تست دستی
هنگامی که شما توسعه یک ویژگی جدید منطقی است و همچنین تست آن را به صورت دستی. شما می توانید آن را با مراحل زیر:
ساخت خانه کلیک. اجرای کلیک از ترمینال: تغییر دایرکتوری به programs/clickhouse-server و با ./clickhouse-server. این پیکربندی استفاده کنید (config.xml, users.xml و فایل ها در config.d و users.d دایرکتوری ها) از دایرکتوری جاری به طور پیش فرض. برای اتصال به سرور کلیک اجرا کنید programs/clickhouse-client/clickhouse-client.
توجه داشته باشید که تمام clickhouse ابزار (سرور مشتری و غیره) فقط symlinks به یک باینری به نام clickhouse. شما می توانید این دودویی در programs/clickhouse. همه ابزار همچنین می توانید به عنوان استناد شود clickhouse tool به جای clickhouse-tool.
متناوبا شما می توانید بسته بندی کلیک را نصب کنید: در هر صورت انتشار پایدار از مخزن یاندکس و یا شما می توانید بسته را برای خودتان با ساخت ./release در منابع کلیک خانه ریشه. سپس سرور را با شروع sudo service clickhouse-server start (یا توقف برای متوقف کردن سرور). به دنبال سیاهههای مربوط در /etc/clickhouse-server/clickhouse-server.log.
هنگامی که تاتر در حال حاضر بر روی سیستم شما نصب شده, شما می توانید جدید ساخت clickhouse دودویی و جایگزین باینری موجود:
$ sudo service clickhouse-server stop
$ sudo cp ./clickhouse /usr/bin/
$ sudo service clickhouse-server start
همچنین شما می توانید سیستم کلیک سرور را متوقف و اجرا خود را با همان پیکربندی اما با ورود به ترمینال:
$ sudo service clickhouse-server stop
$ sudo -u clickhouse /usr/bin/clickhouse server --config-file /etc/clickhouse-server/config.xml
به عنوان مثال با دیابت بارداری:
$ sudo -u clickhouse gdb --args /usr/bin/clickhouse server --config-file /etc/clickhouse-server/config.xml
اگر سیستم کلیک-سرور در حال اجرا است و شما نمی خواهید برای متوقف کردن, شما می توانید شماره پورت در خود تغییر دهید config.xml (یا نادیده گرفتن در یک فایل در config.d فهرست راهنما) مسیر داده مناسب را فراهم کرده و اجرا کنید.
clickhouse دودویی تقریبا هیچ وابستگی و کار در سراسر طیف گسترده ای از توزیع های لینوکس. برای تست سریع و کثیف تغییرات خود را بر روی یک سرور, شما به سادگی می توانید scp تازه ساخته شده است clickhouse باینری به سرور شما و سپس به عنوان مثال بالا اجرا شود.
محیط تست
قبل از انتشار انتشار به عنوان پایدار ما را در محیط تست استقرار. محیط تست یک خوشه است که بخشی از 1/39 را پردازش می کند یاندکسمتریکا داده ها. ما محیط تست خود را با یاندکس به اشتراک می گذاریم.تیم متریکا تاتر بدون خرابی در بالای داده های موجود به روز رسانی. ما در ابتدا نگاه کنید که داده ها با موفقیت و بدون عقب مانده از زمان واقعی پردازش, تکرار ادامه کار و هیچ مشکلی برای یاندکس قابل مشاهده وجود دارد.تیم متریکا اولین چک را می توان در راه زیر انجام داد:
SELECT hostName() AS h, any(version()), any(uptime()), max(UTCEventTime), count() FROM remote('example01-01-{1..3}t', merge, hits) WHERE EventDate >= today() - 2 GROUP BY h ORDER BY h;
در برخی موارد ما نیز به تست محیط زیست از تیم های دوست ما در یاندکس استقرار: بازار, ابر, و غیره. همچنین در حال حاضر برخی از سرورهای سخت افزاری است که برای اهداف توسعه استفاده می شود.
تست بار
پس از استقرار به محیط تست ما تست بار با نمایش داده شد از خوشه تولید را اجرا کنید. این کار به صورت دستی انجام می شود.
اطمینان حاصل کنید که شما را فعال کرده اند query_log در خوشه تولید خود را.
جمع کردن گزارش پرس و جو برای یک روز یا بیشتر:
$ clickhouse-client --query="SELECT DISTINCT query FROM system.query_log WHERE event_date = today() AND query LIKE '%ym:%' AND query NOT LIKE '%system.query_log%' AND type = 2 AND is_initial_query" > queries.tsv
این یک مثال راه پیچیده است. type = 2 نمایش داده شد که با موفقیت اجرا فیلتر کنید. query LIKE '%ym:%' است برای انتخاب نمایش داده شد مربوطه از یاندکس.متریکا is_initial_query است را انتخاب کنید تنها نمایش داده شد که توسط مشتری شروع, نه با کلیک خود (به عنوان بخش هایی از پردازش پرس و جو توزیع).
scp این ورود به خوشه تست خود را و اجرا به شرح زیر است:
$ clickhouse benchmark --concurrency 16 < queries.tsv
(احتمالا شما همچنین می خواهید برای مشخص کردن یک --user)
پس یه شب یا هفته ولش کن و برو استراحت کن
شما باید بررسی کنید که clickhouse-server سقوط نمی کند, رد پای حافظه محدود است و عملکرد در طول زمان تنزل نمی.
زمان اجرای پرس و جو دقیق ثبت نشده است و با توجه به تنوع بالا از نمایش داده شد و محیط زیست در مقایسه نیست.
ساخت تست
تست های ساخت اجازه می دهد تا بررسی کنید که ساخت در تنظیمات مختلف جایگزین و در برخی از سیستم های خارجی شکسته نمی شود. تست ها در واقع ci فهرست راهنما. ساخت از منبع داخل کارگر بارانداز ولگرد و گاهی با اجرا می شوند qemu-user-static در داخل کارگر بارانداز. این تست ها در حال توسعه هستند و تست اجرا می شود خودکار نیست.
انگیزه:
به طور معمول ما انتشار و اجرای تمام تست بر روی یک نوع واحد از ساخت تاتر. اما انواع ساخت جایگزین است که به طور کامل تست شده وجود دارد. مثالها:
- ساخت در بورس;
- ساخت در دبیان با کتابخانه ها از بسته های سیستم;
- ساخت با لینک مشترک از کتابخانه ها;
- ساخت پلت فرم AArch64;
- ساخت بر روی پلت فرم پاور.
مثلا, ساخت با بسته های سیستم عمل بد است, چرا که ما نمی تواند تضمین کند که چه نسخه دقیق از بسته های یک سیستم باید. اما این واقعا توسط نگهداری دبیان مورد نیاز است. به همین دلیل ما حداقل باید برای حمایت از این نوع ساخت. مثال دیگر: ارتباط مشترک یک منبع مشترک از مشکل است, اما برای برخی از علاقه مندان مورد نیاز است.
هر چند ما می توانیم تمام تست در همه نوع از ایجاد اجرا کنید, ما می خواهیم برای بررسی حداقل که انواع ساخت های مختلف شکسته نمی. برای این منظور ما از تست های ساخت استفاده می کنیم.
تست برای سازگاری پروتکل
هنگامی که ما گسترش clickhouse پروتکل شبکه ما تست دستی که clickhouse-مشتری با این نسخهها کار جدید clickhouse-سرور و جدید clickhouse-مشتری با این نسخهها کار با clickhouse-سرور (به سادگی با در حال اجرا فایل های باینری از مربوطه بسته).
کمک از کامپایلر
کد اصلی کلیک (که در واقع dbms فهرست راهنما) با ساخته شده است -Wall -Wextra -Werror و با برخی از هشدارهای اضافی را فعال کنید. اگر چه این گزینه ها برای کتابخانه های شخص ثالث فعال نیست.
کلانگ هشدارهای بیشتری دارد - شما می توانید با -Weverything و انتخاب چیزی به طور پیش فرض ساخت.
برای تولید ساخت, شورای همکاری خلیج فارس استفاده می شود (هنوز تولید کد کمی موثر تر از صدای جرنگ جرنگ). برای توسعه, صدای جرنگ جرنگ است که معمولا راحت تر به استفاده از. شما می توانید بر روی دستگاه خود را با حالت اشکال زدایی ساخت (برای صرفه جویی در باتری لپ تاپ خود را), اما لطفا توجه داشته باشید که کامپایلر قادر به تولید هشدارهای بیشتر با است -O3 با توجه به جریان کنترل بهتر و تجزیه و تحلیل بین روش. هنگام ساخت با صدای جرنگ جرنگ, libc++ به جای استفاده libstdc++ و هنگامی که ساختمان با حالت اشکال زدایی, نسخه اشکال زدایی از libc++ استفاده شده است که اجازه می دهد تا برای گرفتن خطاهای بیشتر در زمان اجرا.
Sanitizers
نشانی ضد عفونی کننده. ما تست های کاربردی و یکپارچه سازی را تحت عنوان بر اساس هر متعهد اجرا می کنیم.
Valgrind (Memcheck).
ما یک شبه تست های کاربردی را تحت ارزیابی قرار می دهیم. چند ساعت طول می کشد. در حال حاضر یک مثبت کاذب شناخته شده در وجود دارد re2 کتابخانه را ببینید این مقاله.
تعریف نشده رفتار ضد عفونی کننده. ما تست های کاربردی و یکپارچه سازی را تحت عنوان بر اساس هر متعهد اجرا می کنیم.
ضدعفونی کننده موضوع. ما تست های کاربردی تحت تسان بر اساس هر مرتکب اجرا. ما هنوز تست های ادغام تحت تسان بر اساس هر متعهد اجرا کنید.
ضد عفونی کننده حافظه. در حال حاضر ما هنوز از خانم استفاده نمی کنیم.
اشکال زدایی تخصیص.
نسخه اشکال زدایی از jemalloc برای ساخت اشکال زدایی استفاده می شود.
Fuzzing
ما با استفاده از تست ریش ریش شدن ساده برای تولید پرس و جو تصادفی گذاشتن و بررسی کنید که سرور نمی میرند. تست ریش شدن با نشانی ضد عفونی کننده انجام می شود. شما می توانید این را در 00746_sql_fuzzy.pl. این تست باید به طور مداوم اجرا شود (یک شبه و طولانی تر).
همانطور که از دسامبر 2018, ما هنوز تست ریش شدن جدا شده از کد کتابخانه استفاده نمی.
ممیزی امنیتی
مردم از یاندکس ابر بخش انجام برخی از بررسی اجمالی اساسی از قابلیت های تاتر از نقطه نظر امنیت.
تجزیه و تحلیل استاتیک
فرار میکنیم PVS-Studio بر اساس هر مرتکب. ما ارزیابی کرده ایم clang-tidy, Coverity, cppcheck, PVS-Studio, tscancode. شما دستورالعمل برای استفاده در پیدا tests/instructions/ فهرست راهنما. همچنین شما می توانید به عنوان خوانده شده مقاله در روسیه.
در صورت استفاده CLion به عنوان محیط برنامه نویسی, شما می توانید اهرم برخی از clang-tidy چک از جعبه.
سخت شدن
FORTIFY_SOURCE به طور پیش فرض استفاده می شود. این تقریبا بی فایده است, اما هنوز هم حس می کند در موارد نادر و ما این کار را غیر فعال کنید.
سبک کد
قوانین سبک کد شرح داده شده است اینجا.
برای بررسی برخی از نقض سبک مشترک, شما می توانید استفاده کنید utils/check-style خط نوشتن.
به زور سبک مناسب از کد خود را, شما می توانید استفاده کنید clang-format. پرونده .clang-format در منابع ریشه واقع شده است. این بیشتر با سبک کد واقعی ما مطابقت دارد. اما توصیه نمی شود که اعمال شود clang-format به فایل های موجود چون باعث می شود قالب بندی بدتر است. شما می توانید استفاده کنید clang-format-diff ابزاری است که شما می توانید در مخزن منبع صدای جرنگ جرنگ پیدا.
متناوبا شما می توانید سعی کنید uncrustify ابزار مجدد کد خود را. پیکربندی در uncrustify.cfg در منابع ریشه. این کمتر از تست شده است clang-format.
CLion فرمت کد خود را دارد که باید برای سبک کد ما تنظیم شود.
تست های متریکا ب2
هر clickhouse نسخه تست شده با yandex metrica و appmetrica موتورهای. تست و نسخه های پایدار از تاتر در ماشین های مجازی مستقر و اجرا با یک کپی کوچک از موتور متریکا است که پردازش نمونه ثابت از داده های ورودی. سپس نتایج حاصل از دو نمونه از موتور متریکا با هم مقایسه می شوند.
این تست ها توسط تیم جداگانه خودکار می شوند. با توجه به تعداد زیادی از قطعات متحرک, تست شکست بیشتر از زمان به دلایل کاملا نامربوط, که بسیار دشوار است برای کشف کردن. به احتمال زیاد این تست ها ارزش منفی برای ما دارند. با این وجود این تست در حدود یک یا دو بار از صدها مفید ثابت شد.
پوشش تست
تا جولای 2018 ما پوشش تست را پیگیری نمی کنیم.
اتوماسیون تست
ما تست ها را با سیستم اتوماسیون داخلی یاندکس اجرا می کنیم “Sandbox”.
ساخت شغل و تست ها در گودال ماسهبازی در هر مرتکب اساس اجرا شود. نتیجه بسته ها و نتایج تست در گیتهاب منتشر شده و می تواند توسط لینک مستقیم دانلود. مصنوعات ابد ذخیره می شود. هنگامی که شما یک درخواست کشش ارسال در گیتهاب, ما برچسب به عنوان “can be tested” و ما CI سیستم خواهد ساخت ClickHouse بسته (نسخه debug با آدرس ضد عفونی کننده و غیره) را برای شما.
ما از تراویس سی به دلیل محدودیت در زمان و قدرت محاسباتی استفاده نمی کنیم. ما از جنکینز استفاده نمیکنیم. این قبل از استفاده شد و در حال حاضر ما خوشحال ما با استفاده از جنکینز نیست.
مقاله اصلی velopment/آزمون/)