ايميل:

كلمه عبور:


مرا از مطلب‌های جدید باخبر کن!
ايميل من:


فهرست مطالب


ارائه توسط: Mike Barker
مترجم: سید مرتضی هاشمی 1396/04/05
در این قسمت که در آوریل ۲۰۱۶ منتشر شده است مایکل بارکر با سوِن یوهان درباره‌ی معماری سامانه‌ی LMAX صحبت می‌کنند. بارکر یک برنامه‌نویس تحقیق و توسعه است و قبلاً در LMAX (London Multi Asset eXchange) مدیر نرم‌افزار بوده است. مایکل عضوی فعال در انجمن جاوا است و به صورت پراکنده در پروژه‌های متن‌باز از جمله GNU Class Path و Jboss و Mono شرکت می‌کند. در حال حاضر او در نیوزیلند زندگی می‌کند و به صورت دورکاری با LMAX همکاری می‌کند. LMAX یک بستر (Platform) با تأخیر (Latency) پایین و توان عملیاتی (Throughput) بالا، برای بورس است. از جمله مباحث مطرح شده در این مصاحبه می‌توان به این موارد اشاره نمود: LMAX چه می‌کند؟ منشأ LMAX کجاست؟ نیازمندی‌های شدید کارایی که LMAX با آن روبروست کدامند؟ سامانه‌ها و کاربرانی که LMAX با آن‌ها ارتباط برقرار می‌کند چه هستند؟ دو مؤلفه‌ی اصلیِ سامانه (کارگزار و بورس) چه هستند؟ چطور درک مکانیکی به عنوان یک محرکِ معماری بر LMAX تأثیر گذاشته است؟ گردش (Flow) پیام با استفاده از کتابخانه‌ی LMAX Disruptor چطور انجام می‌شود؟ الگوریتم‌های بدون قفل (Lock-free) چه هستند؟
مایک به برنامه خوش آمدی.
متشکرم سوِن.
آیا چیز مهمی را درباره‌ی شما فراموش کردم؟
در مورد چیزهای متن‌باز، تنها کاری که در حال حاضر انجام می‌دهم نگهداری LMAX Disruptor است که مطمئنم در مورد آن صحبت خواهیم کرد.
باشه. برای زمینه‌سازی [به ما بگویید] LMAX و Betfair چه هستند؟
با Betfair شروع می‌کنیم، چون بخش مهمی از تاریخ‌مان است. Betfair یک بستر شرط‌بندیِ ورزشیِ نظیر به نظیر (Peer to Peer) است؛ ورزش‌هایی از قبیل اسب‌سواری، فوتبال و ... . سال‌ها پیش قبل از آن که من با LMAX کار کنم، آن‌ها پروژه‌ای داشتند که می‌خواستند ساختن سامانه‌ای بسیار کارامد برای بورس را امتحان کنند؛ چیزی که صدها برابر از آن‌چه که در حال حاضر دارند، کارامدتر باشد. چون داد و ستدهای شرط‌بندی و داد و ستدهای مالی از لحاظ فنی کاملاً به هم شبیه‌اند. در هر دو، مفاهیم قیمت و مقدار را دارید، در سامانه شرط‌بندی تطبیق دادن (Match) افراد بر اساس شانس است و در سامانه مالی هم بر اساس قیمت است. بنابراین یک پروژه‌ی تحقیقاتی را راه‌اندازی کردند. در این زمینه به اکتشافات جالبی دست پیدا کردند که یک بورس چطور باید کار کند. آن‌ها تصمیم گرفتند برخی از این ایده‌ها را گرفته و شرکتی به نام Tradefair را راه‌اندازی کنند. بنابراین بسیاری از ایده‌های پروژه‌ی تحقیقاتی را -البته نه اصل کدها را-گرفتند و چیزی را ساختند که به تدریج به بورس LMAX تبدیل می‌شد. بعد از مدتی نام تجاری را تغییر دادند و از نام Tradefair فاصله گرفتند. از آن پس Betfair مالکیت LMAX را در اختیار داشته است. چند سال پیش سهم مدیریت توسط مدیر عامل خریده شد. بنابراین مالکیت LMAX الان کمی مستقل‌تر است. Betfair هنوز هم سهم دارد اما در حال حاضر بخش زیادی از LMAX تحت مالکیت مدیرعامل و کارمندان است.
آیا می‌توانید یک موردِ کاربرد متداول کسب و کار را برای LMAX نام ببرید؟ یک سفارش چیست؟
باشه. احتمالاً این را در توضیحات اولیه جا انداختم. LMAX چیست؟ ما به دنبال ساختن چیزی به نام (Contract For Difference) یا به اختصار CFD هستیم یعنی قراردادی برای داد و ستدهای مالی برای معامله‌ی هر جور دارایی از قبیل انتخاب‌ها (Options)، آینده‌ها (Futures)، و FX ها (Forex) و … . در‌واقع محصولاتی را درنظر بگیرید که تمام قیمت را پرداخت نمی‌کنید بلکه مشتقی از آن را می‌پردازید. در واقع به نحوی تکامل پیدا کردیم که بیشتر تمرکزمان بر فضای بورس خارجی باشد. خود LMAX در بورس FX اجرا می‌شود. ما این کار را برای بخش‌های مختلف بازار انجام می‌دهیم که به آن بورس حرفه‌ای می‌گوییم که بخش زیادی از آن کارگزاران و افراد ثروتمند هستند. بورس مؤسسات را داریم که به نوعی گران‌قیمت‌ترین داد و ستدها در آن انجام می‌شود. بورس بین بانکی را هم داریم که صراحتاً برای بانک‌هاست. برخی اصطلاحات هستند که در این صنعت کار با بورس متداول‌اند. مفاهیمی که می‌خواهیم در مورد آن صحبت کنیم، فرمان‌ها (Instructions)، سفارش‌ها (Orders) و معاملات (Trades)، و اجرا (Execution) هستند. در ابتدا کسی چیزی را در قالب یک پیام می‌بیند که می‌گوید می‌خواهم سفارش بدهم یا سفارش را لغو کنم. ما اصطلاحاً به این‌ها فرمان می‌گوییم. بنابراین پیام‌هایی که از مشتریان و فروشندگان دریافت می‌کنیم فرمان هستند. زمانی که [فرمان‌ها] به بورس می‌رسند، اجرا می‌شوند و چیزی را می‌سازند که به آن «اجرا» می‌گوییم. اجرا چیزی است که در بورس اتفاق افتاده است. در نتیجه‌ی یک اجرا می‌توانیم یک سفارش ایجاد کنیم، آن را لغو کرده یا جابجا کنیم. بنابراین یک سفارش، موجودیتی است که در بورس زندگی می‌کند و عمدتاً نوعی قیمت و مقدار دارد؛ قیمت می‌تواند اختیاری باشد. برخی سفارش‌ها مدتی در بورس می‌مانند و برخی ممکن است بلافاصله اجرا شوند. در اینجا خود سفارش‌ها هستند که جالب‌اند. اگر فرمان برای ایجاد یک سفارش با یک قیمت و مقدار مشخص بفرستید، این فرمان در جعبه‌ی سفارش‌ها قرار می‌گیرد و قیمتی خواهد داشت. بورس ما مسئول سفارش دادن این سفارش‌ها، بر اساس زمان رسیدن به بورس و قیمت تعیین‌شده است. سفارش‌های خرید، بر اساس بالاترین قیمت مرتب شده و پیشنهاد شوند. سفارش‌های فروش هم بر اساس کم‌ترین قیمت مرتب شده و پیشنهاد می‌شوند. هدف این است که همواره بهترین قیمت بازار را پیدا کنید. به محض این‌که سفارش‌هایی دریافت کنیم که قیمت‌های آن‌ها تطابق پیدا کند (سفارش خرید و سفارش فروشی که قیمت‌هایشان یکسان است یا همپوشانی دارد) داد و ستد اتفاق می‌افتد. در کاربرد ما ارز است [که داد و ستد می‌شود] اما می‌تواند پولی برای خرید کالا یا ... باشد. این مفهوم تجارت است که در آن دو طرف، چیزی را داد و ستد می‌کنند. این‌ها احتمالاً پنج مفهوم اصلی در یک بورس مالی هستند.
ادامه مطلب ...

ارائه توسط: Bjorn Rabenstein
مترجم: محمدرضا دهقانی‌زاده 1396/03/30
در این مصاحبه که در دسامبر ۲۰۱۶ منتشر شده است، رابرت بلومن با بیورن رابنستین در ارتباط با موضوع «مهندس اتکاپذیری سایت» (Site Reliability Engineer) گفتگو می‌کند. بیورن یک مهندس محصول در SoundCloud و یکی از توسعه‌دهندگان اصلی Prometheus است. سابق بر این او در گوگل یک SRE و پژوهش‌گر در زمینه‌ی مدلینگ مولکولی بوده است.
بیورن به رادیو مهندسی نرم‌افزار خوش آمدی.
از لطف شما ممنونم.
خیلی عالی هست که اینجا هستید، امروز من و بیورن در مورد «مهندسی اتکاپذیری سایت» گفتگو خواهیم داشت. به خاطر تکرار زیاد، من به اختصار از SRE استفاده می‌کنم پس منظورم از SRE همان مهندسی اتکاپذیری سایت هست. ما در مورد تجربه‌ی بیورن و ایده‌های بسیاری از کتاب Site Reliability Engineering: How Google Runs Production Systems که در سال اخیر منتشر شده صحبت خواهیم کرد.
بیورن، تمایل دارید بخش‌هایی از سوابق خودتان را که شاید من جا انداخته باشم، برای شنونده‌ها بگویید؟
شما زندگی نامه‌ی من را خیلی مختصر گفتید. من در دو جا شاغل بوده ام. دو استخدام عادی در زندگی‌ام داشته‌ام: یکی همین الان که SoundCloud هستم؛ جالبه که فردا سالگرد سومین سال کارم است و قبل از آن هم همانطور که شما گفتید هفت سال و اندی در گوگل به عنوان مهندس اتکاپذیری سایت حضور داشتم. پیش از گوگل هم در اواخر حبابِ دات‌کام ( Dotcom Bubble ) به صورت آزاد، کار می‌کردم. در اصل من یک دانشمند هستم و می‌خواستم صرفاً پژوهشهای علمی انجام بدهم، نه در علوم کامپیوتر، بلکه در علوم هستی شناسی. بنا به دلایلی من گیر افتادم و لاجرم در کامپیوتر باقی ماندم.
بیورن من تقریباً ۱ سال هست که در زمینه‌ی DevOps کار می‌کنم اما این کلمه را از شش یا هفت سال پیش می‌شنیدم. ما قبلاً دو برنامه در این مورد داشتیم، قسمت ۲۴۷ و قسمت ۲۶۸ که در مورد زیرساخت به منزله‌ی کد (Infrastructure as Code) بود. من گوش دادن به آنها را به عنوان پیش‌زمینه‌ی این برنامه به شنوندگان توصیه می‌کنم.
در سال اخیر من عبارت SRE را می‌شنوم. آیا SRE نام دیگری برای DevOps است یا چیزی بیشتر از آن است؟
این واقعاً سؤال خوبی است. در واقع کلمه‌ی SRE در گوگل ایجاد شد. اگر اشتباه نکنم کلمه‌ی DevOps تقریباً از سال ۲۰۰۸ متولد شد. من مطمئن نیستم که کلمه‌ی SRE از چه زمانی در گوگل استفاده می‌شد. فکر می‌کنم بنجامین ترینور که رئیس کل دپارتمان هست در سال ۲۰۰۳ استخدام شده بود. من در سال ۲۰۰۵ مصاحبه داشتم و سال ۲۰۰۶ به شرکت ملحق شدم و قبل از آن زمان هم این کلمه وجود داشت.
هنوز به خاطر دارم که وقتی کلمه‌ی DevOps بوجود آمد، من خوشحال بودم، چون بالاخره می‌توانستم برای دیگران توضیح بدهم که چه کاری انجام می‌دهم. من احساس می‌کردم که اگر بگویم «من یک جور DevOps در گوگل هستم» توضیح شسته و رفته‌ای هست. بعد متوجه شدم که این باعث سردرگمی بیشتری می‌شود چرا که واقعاً اینطور نیست و تفاوت‌های زیادی بین SRE و DevOps وجود دارد. DevOps شامل چیزهای خیلی زیادی میشود. مردم برداشت‌های متفاوتی از کلمه‌ی DevOps دارند. حدس می‌زنم شما در برنامه‌های قبلی در مورد این مسأله بحث کرده‌اید. البته چون من به دقت از آن‌ها اطلاع ندارم نمی‌توانم بگویم. فکر می‌کنم منظور بسیاری از افراد از DevOps این هست که: «خب، ما توسعه (dev) و عملیات (ops) را داریم و الان این‌ها به خوبی در کنار همدیگر قرار گرفته‌اند و ما به آن DevOps می‌گوییم». واضح است که این تعریف، آن چیزی که باید باشد نیست و خیلی هم با دیدگاه SRE در گوگل تفاوت دارد.
از طرف دیگر، خصوصا الان که من در SoundCloud هستم، ما یک دیدگاه خاص به DevOps داریم که بیشتر شبیه این هست که: «بله، ما توسعه‌دهنده‌های اختصاصی و افراد عملیاتی اختصاصی نداریم، ما هر دوی آنها هستیم». به شکلی یعنی همه هر دوی آنها هستند. این یک تفسیر دیگر از DevOps است که احتمالاً چیزی نیست که منظور بسیاری از مردم است. همینطور این با منظور گوگل از SRE متفاوت است.
من حدس می‌زنم که یک همپوشانی وجود دارد که آنها به خوبی در کتاب آن را بیان کرده‌اند. در اوائل بخش مقدمه، یک کادر وجود دارد که در آنجا ارتباط بین DevOps و SRE را توضیح داده‌اند. ما می‌توانیم در این باره با جزئیات بیشتری صحبت کنیم ولی شاید این سؤال اولیه‌ی شما را پاسخ بدهد.
ادامه مطلب ...

ارائه توسط: Dwight Merriman
مترجم: محمد علی بزرگ زاده 1396/03/19
در این قسمت، رابرت بلومن در حاشیه کنفرانس Mongo در سانفرانسیسکو با دوآیت مریمن درباره‌ی NoSQL و اقبالی که به آن شده است صحبت می‌کنند. دوآیت مدیرعامل و از بنیانگذاران شرکت MongoDB است که حامی صنعتی پایگاه داده متن‌باز MongoDB است. در این مصاحبه به این موارد اشاره می‌شود: NoSQL و ۳ نوع ذخیره‌گاه غیررابطه‌ای مطرح در آن، قضیه CAP و تضمین‌های سازگاری ضعیف‌تری که می‌توان در پایگاه‌ داده‌های توزیع‌شده داشت، ذخیره‌گاه‌‌های سندگرا (Document-oriented)، نیازهای ذخیره‌سازی برنامه‌های نوین تحت وب و پایگاه داده متن‌باز MongoDB.
به رادیوی مهندسی نرم‌افزار خوش آمدی دوآیت!
متشکرم.
من با شما در مورد NoSQL و پایگاه Mongo صحبت می‌کنم. لطفاً ابتدا کمی در مورد سابقه‌تان با مخاطبان‌مان صحبت کنید.
از نظر سابقه فنی، من به عنوان یک توسعه‌دهنده شروع کردم. من از بنیانگذاران و مدیرفنی DoubleClick بودم.. فناوری اصلی آن را ساختم و بعد از DoubleClick شرکت جدیدی با نام 10gen را شروع کردیم که منشأ و حامی پروژه MongoDB است.
شما یک ارائه دارید که در اینترنت هم در دسترس است و گذار به دنیای غیررابطه‌ای نام دارد. چرا دنیا به این سمت حرکت می‌کند؟
سرعت‌دهنده‌ی اصلی آن، میل به مقیاس‌پذیری افقی (Horizontal Scalability) است. چرا که مقیاس دادن افقی یک پایگاه سنتی رابطه‌ای مسأله بسیار سختی است. اگر فرضی در مورد شِمای داده‌ها نداشته باشید، انجام عملیات‌های الحاق توزیع‌شده (Distributed Join) خیلی سخت است. به علاوه، انجام تراکنش‌های توزیع‌شده پرهزینه است. بنابراین به نظر من به راه‌حل‌های ذخیره داده‌ای نیاز بود که به سادگی به شکل افقی افزایش مقیاس داده شوند و اگر الحاق‌ها و تراکنش‌های پیچیده را کنار بگذاریم می‌توانیم این کار را بکنیم. بنابراین این‌ها ویژگی‌های راه‌‌حل‌های غیررابطه‌ای جدید است. علتی که این فضا شکل گرفت، این بود که یک میل به مقیاس‌پذیری افقی وجود داشت. به علاوه، فکر می‌کنم فرصتی هم برای نوآوری در ارتباط با مثلاً مدل‌های داده، وجود دارد و حال که کارهایی می‌کنیم که رابطه‌ای نیست مزایای دیگری از جمله سادگی توسعه را هم بدست آورده‌ایم.
چرا طی ۲۰ سال گذشته، پایگاه‌های رابطه‌ای بازار ذخیره‌گاه‌ها را تصرف کرده‌اند؟
سئوال خوبی است. از لحاظ نظری، پایگاه‌های رابطه‌ای ۴۰ سال عمر دارند بنابراین یکی از پرعمرترین و موفق‌ترین فناوری‌های تاریخ به شمار می‌روند. چیزی که عمرش بیش از آن باشد را در ذهن ندارم و خیلی خوب هم کار کرده‌اند. فکر می‌کنم یکی از عوامل کلیدی‌اش این است که مزایای چشمگیری در ناهمبسته کردن (Decoupling) مفاهیم ذخیره‌گاه و مدل داده با امور برنامه و کد وجود دارد. سیستم‌های معظم (Enterprise) شامل برنامه‌های کاربردی زیادی هستند و از زبان‌های برنامه‌نویسی زیادی استفاده می‌کنند و این زبان‌ها در طی زمان تغییر می‌کنند. هرچند سال یکبار، زبان جدیدی می‌آید. بنابراین نمی‌خواهیم که داده‌های‌مان به کد، زیادی همبسته شود. فکر می‌کنم در روزهای اولیه پایگاه‌های اشیاء (Object Databases) این مسأله کمی وجود داشته است. اما چیز خوبی که در مورد رابطه‌ای‌ها هست این است که هیچ زبان برنامه‌نویسی رابطه‌ای وجود ندارد و در واقع رابطه‌ها انواع داده‌ای هستند. این به خوبی از محیط کدنویسی مجزا شده است اما بر خلاف انتظار مشخص شد که مفید است چون ممکن است تکه‌کدهای خیلی زیادی داشته باشید و زبان‌های مختلف زیادی داشته باشید و کد پیچیده می‌شود و اگر قرار باشد برای فهمیدن کد، مجبور باشیم داده‌ها را بفهمیم، مشکل می‌شود. به علاوه روشن شد که SQL چیز واقعاً قدرتمندی است که واسطه زیبایی بین کلاینت و سرور این برنامه‌ها می‌آورد و استانداردهایی حول آن دارد که این چیز خوبی است و چیزی است که بر روی مفاهیم رابطه‌ای بنا شده است.
ادامه مطلب ...