سوال در خصوص دیتابیس درون حافظه با قابلیت sql query

[mehdi einali]

سلام به همه دوستان

ما در نارون درگیر تولید محصولاتی در حوزه بازار سرمایه هستیم. برای خیلی از موارد نظیر Algorithmic trading نیاز داریم که داده هایی تقریبا ساخت یافته ای رو توی حافظه نگهداری که با نرخ زیادی به روزرسانی می شوند و با ساختاری شبیه sql جستجو می شوند.

برای این کار گزینه اولمون استفاده از Redis (به عنوان db اصلی درون حافظه مون) بود که به دلیل نداشتم داده ساختار قابل جستجو شدنی نیست. یک ماجول redisql وجود داره که یک بنده خدا نوشته ولی خیلی بروز نیست.

بعدش گزینه های بعدی که بررسی کردم استفاده از hazelcast , aerospike بود که هر دو دیتابیس درون حافظه هستند و sql compatible هستند ولی چون هر دو نسخه تجاری دارند نسخه بازمتن شون خیلی قابل اتکا برای پشتیبانی از امکانات به نظر نمیاد.

در مورد hazelcast  یک مشکل دیگه هم اینه که به نظر خیلی زیادی جاوا محور است حتی نسخه کلاینت پایتونش که ما می خوایم استفاده کنیم یک نسخه از کلاینت جاوا عقب تره.

می خواهم بدونم کسی پیشنهادی در این خصوص داره؟

با مشورتی که با سیدجمال کردم بنا به توصیه مهران استفاده fundationdb رو پیشنهاد داد ولی نمی دونم به این کار میاد یانه.

مهران جان شما که تجربه کار توی بازارهای مالی رو دارید پیشنهادی در این خصوص دارید؟

@meh...@gmail.com

ما برای TimeSeries DB هم از ElasticSeach استفاده می کنیم . بیشتر به خاطر اینکه بهش مسلط بودیم. در این خصوص هم اگر کسی نظری داره خوشحال می شم بفرمایید.

هر کسی نظری در خصوص این موارد داره ممنون می شم که بهم بگید.

ارادتمند

[Seyyed Jamaleddin Pishvayi]

بسم الله الرحمن الرحیم

سلام علیکم

برای این جور کارها event sourcing و actor model هم خیلی خوب جواب میده. نخ سوزن 25 آبان یکی از اوتاد اعوان در جاوا ویژن ارائه پرفکتی در مورد actor model خواهند داشت که اگر از دست بدید پشیمونی دیگه سودی نداره. 

--
You received this message because you are subscribed to the Google
Groups "ASTA Development List" group.
To post to this group, send email to
asta-devel...@googlegroups.com
To unsubscribe from this group, send email to
asta-development...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/asta-development-list?hl=en
or
http://www.asta.ir
---
You received this message because you are subscribed to the Google Groups "ASTA Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to asta-development...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/asta-development-list/CA%2BK1daP1kvWFv3Z2BwKuj4dXdnuqz8T7F%2BxZGKD6VHdkb%2BZmfw%40mail.gmail.com.

[mehdi einali]

اقا من خیلی حس مثبتی به این foundationdb ندارم

انگار اصلا خیلی مورد توجه نیست!

To view this discussion on the web visit https://groups.google.com/d/msgid/asta-development-list/CALcN8y_hPbPMxsxnZqs1goJhu%3D0BTZx7mHYS6spuKBK05N0c6Q%40mail.gmail.com.

[Seyyed Ehsan Mahmoudi]

سلام و عرض ارادت به همه  دوستان اعوانی

ما در یکی از پروژه ها  برای integration test به جای این که به دنبال پیدا کردن معادل in memory هر یک از اجزا باشیم تصمیم گرفتیم با استفاده از داکر و  ماونت کردن فایل سیستم در حافظه به کانتینر سرعت کار رو بالا  ببریم. 

نمی دونم چقدر این کار برای محیط پروادکشن درست هست ولی از دید یک گزینه شاید کمک کننده باشد. 

To view this discussion on the web visit https://groups.google.com/d/msgid/asta-development-list/CALcN8y_hPbPMxsxnZqs1goJhu%3D0BTZx7mHYS6spuKBK05N0c6Q%40mail.gmail.com.

[حمید حق‌شناس‎]

سلام به شما و سایر دوستان

اگر داده‌هایی که می‌فرمایید، حجیم هستند و باید بصورت طولانی‌مدت ماندگار باشند،
گزینه‌های nosql از جمله elasticsearch که فرمودید و همچنین mongodb ارزش بررسی رو داره.
بطور کلی، نیاز به پایگاه‌داده درون‌حافظه با داده‌های بسیار زیاد و طولانی‌مدت، به نظرم کمی شک‌برانگیز هست.

گاهی با پیش‌پردازش‌های هوشمندانه میشه داده‌ها رو بهینه‌تر ذخیره کرد،
به این صورت که crawlerها به‌روزرسانی‌ها رو در کافکا بریزند و پردازه‌هایی اونها رو consume و بعد از پیش‌پردازش در پایگاه‌داده ذخیره کنند.
این کار، برنامه‌نویس رو از این دغدغه که داده‌های دریافتی (به دلیل ضیق وقت) عیناً باید در پایگاه‌داده منعکس بشن و همه بار پردازشی تحلیل داده روی پایگاه‌داده بیفته آزاد می‌کنه.

همچنین، گاهی با profile کردن کد، گلوگاه‌های عجیبی در کد شناسایی میشه.
مثلاً چند وقت پیش، در یه پروژه پایتون-jupyter که اتفاقاً به تحلیل بازار سرمایه مربوط بود، کندی شدیدی احساس می‌شد و دوستان نگران غیر بهینگی پایگاه‌داده، توان پردازشی سرور و غیره بودند.
با profile کردن مشخص شد یکی از propertyهای تعریف‌شده در jupyter دسترسی بهش O(1)‎ نبوده و در یک حلقه ازش استفاده می‌شد. با یه extract variable ساده، شاخ غول شکست.

در نهایت، اگر حجم عملیات نیازمند چند سرور هست، میشه به ایده‌های شکست کار هم فکر کرد،
چه sharding در سطح داده
و چه actor model که سید فرمودند

با احترام

On Sat, Oct 31, 2020 at 1:36 PM mehdi einali <ein...@gmail.com> wrote:

--

[Mehran Heidarzadeh]

سلام و عرض ارادت!

عرض شود که... انتخاب دیتا استور مناسب خیلی بستگی به خیلی چیزا داره. 

چه جور داده‌ای رو می‌خوای نگه‌داری؟ چه بخشی از داده‌ها دارن مدام عوض می‌شن؟

واقعن SQL نیاز دارید، یا چند مدل کوئری مشخص هست که می‌شه با سیستم‌های ساده‌تر هم پیاده‌سازی کردشون؟

حجم و نسبت نوشتن/خواندن چقدره. لازمه در حافظه باشه؟ یا به خاطر اینکه پروفورمنسش بالا باشه فکر می‌کنید توی حافظه باشه بهتره؟

توی سیستم‌های مالی مربوط با بازار سرمایه، اطلاعات تاریخی رو خیلی وقتا توی sqlite نگه‌می‌دارن. اطلاعات زنده‌ی بازار رو توی حافظه‌ی خود برنامه نگه می‌دارن که سریع باشه. 

من تجربه‌ی مثبتی با FoundationDB دارم. یه شرکت کوچیک بود که محصولش رو اپل خرید و یه مدتی داخلی شرکت روش کار کردن، بعد اپن سورس کردنش. چیز خیلی ساده‌ایه. یه Sorted Key Value Storeه که تراکنش ACID داره. می‌شه لایه‌های دیگه بهش اضافه کنی و باهاش انواع و اقسام دیتابیس‌ها رو پیاده سازی کنی. خودش با چندتا لایه‌ی مختلف می‌آد. مثلا MongoDB-compatible API داره. بعنوان مثال باهاش sqlite رو پیاده‌سازی کردن. 

اگه دیتابیس رابطه‌ای لازم دارید، یه نگاهی به این بندازید:
https://apple.github.io/foundationdb/data-modeling.html#entity-relationship-models

از لحاظ فعال بودن پروژه، اپل به شدت به این پروژه پایبنده چون توی سیستم‌های داخلی خیلی مهمی ازش استفاده می‌کنه. کدش بسیار پایداره، چون مدل تست کردنش خیلی پیشرفته‌ست. پیشنهاد می‌کنم این سخنرانی رو در مورد نحوه‌ی تست کردنش ببینید. من کنفرانس سالیانه‌ش رو پارسال رفتم، بجز آدم‌های اصلی تیم که توی اپل هستن، کلی آدم از خارج از اپل اومدن و در مورد فیچرهایی که بهش اضافه کردن یا روش‌هایی که از این دیتابیس توی سیستمشون استفاده می‌کنن سخنرانی کردن. به نظرم اکوسیستم اپن سورس زنده و قوی‌ای داره. 

مخلص

مهران

To view this discussion on the web visit https://groups.google.com/d/msgid/asta-development-list/CA%2BK1daNhE61mu1SAwFGdQeBJcAV4qKm1-4OPzfXTr0fFDjKJiQ%40mail.gmail.com.

[mehdi einali]

سلام

ممنونم از همه بابت مشارک در بحث

مهران جان بابت توضیحات کامل دستت درد نکنه

راستش شاید من نتونستم خوب مساله مونو تشریح کنم.

سوالی که مطرح کردم در خصوص انتخاب یک دیتابیس با سرعت آپدیت بالا( حدود ۱۰۰۰ تا در ثانیه) با قابلیت پشتیبانی از کوییری ها پیچیده بود( مثلا پشتیبانی از sql).

نیاز برای کویری پیچیده سبب می شد که نتوانیم از ردیس که خیلی منطبق بر داده ساختارهای ساده و مدل key/value هست استفاده کنیم.

پس از بررسی aerospike, hazelcast باتوجه به تفاوت نسخه رایگان و پولی تصمیم گرفتیم از ماجول redisql که در واقع یک sqllite با redis persistance هست استفاده کنیم.

خیلی از این تصمیم راضی نیستم چون برخی امکانات نظیر append only ردیس تو نسخه رایگانش وجود نداره ولی باید تصمیم می گرفتیم تا کارمون پیش بره

  وقت کافی برای تصمیم قطعی نداشتیم ولی حتماFoundationdb رو بار دیگه بررسی می کنم.

همچنان گزینه اولمون برای دادگان سریع اگر مدل کوئیری ها اجازه بده ردیس است. برای داده های تاریخی و حجیم به دلیل تسلطمون به elasticsearch  اونو انتخاب کردیم.

برای استفاده از الگو های شبیه event sourcing ویا reactor model راستش من به دلیل پیچیدگی های مربوط به کسب و کاری در تغییر مداوم نیازمندی ها، با تمام قوا جلو خلاقیت تیم ها رو گرفتم و تنها همه رو مجبور به استفاده از مدل مونولتیک سه لایه کردم. :))

البته در استفاده از MQ و میکروسرویس های خیلی شفاف و متمایز تردید نمی کنیم ولی همه خلاقیت ها به بعد از ارایه MVP ها موکول کردیم و الگوی Monolithic First پیش می رویم.

حتما از ایده های این گفتگو تو ادامه راه استفاده می کنیم.

بازم ممنون از نظرات همه دوستان!

To view this discussion on the web visit https://groups.google.com/d/msgid/asta-development-list/CAJUOZju6CxWjC1rBR3kT2WufywYTKzb2XVhR3v9frWwvUNnVyg%40mail.gmail.com.