Scrimba درخواست راهنمایی در مورد نحوه کارکرد


#1

دوستان این سایت scrimba رو ببینید یک روش آموزش برنامه نویسی هستش
کاری که داره انجام می ده اینه که به جای فیلم در واقع یک جور event recorder درست کردن به نظرم که event های موس و کیبور رو ذخیره می کنن و به همراه صوت و بعد این ها رو پخش می کنن …
حالا سوال اینکه به نظرتون چطوریه این event ها ذخیره می شه ؟ یعنی به نظرتون عاقلانه است که اونت های موس و کیبورد رو با هر تغییر مثلا داخل یک آرایه بزرگ ذخیره کنیم و این آرایه رو بزاریم داخل دیتابیس برای خواندن مجدد ؟
در کل به نظر شما این سایت چطوری کار میکنه ؟ البته منظورم بیشتر همون بخش event recorder اش هست .


#2

خوب یه وقتایی خیلی بهینه تر میشه.
مثلا (یه مثال ساده و متفاوت) من یه عکس دارم که کلا ۵رنگ توش وجود داره (مثلا لوگوی یه شرکته) اگه این عکس با فورمت png باشه، حجم زیادی میگیره. ولی اگه svg باشه (که در حقیقت یه سری دیتای وکتور هست) حجمش خیلی کمتر میشه و هرچقدر هم بزرگ یا کوچیک باشه، حجمی که روی هارد میگیره فرق نمیکنه. (مزایای دیگه ای هم داره که ربطی به حرفمون نداره)
ولی وقتی عکس من 16ملیون رنگ داره (یه عکسیه که از طبیعت گرفتم) وقتی تبدیل به svg بشه، به ازای هر پیکسل باید یه وکتور تو svg داشته باشیم. حتی اگه عکسمون 640x480پیکسل هم باشه، حجم svg ما شاید به چند گیگابایت برسه.

کاری که اینا انجام دادن به نظرم منطقی‌ترین کار ممکنه (سایتشو درست نگاه نکردم. از روی توضیحات شما میگم) با اینکار تنها دیتای خامی که دارن، صدای کسیه که حرف میزنه و عکسهایی که نمایش داده میشه. بقیه‌ی دیتا به صورت text توی دیتابیس ذخیره میشه و این دیتا هم میتونه خیلی راحت با gzip (که این قابلیت رو داره که به صورت stream انکد و دیکد بشه) حجمش خیلی خیلی خیلی کمتر بشه.

من مشابه این کار رو (خیلی هم مشابه نیست ولی تقریبا همین ایده رو دارن) یه جای دیگه هم دیدم.

https://asciinema.org/

دیدنش خالی از لطف نیست و خیلی هم خفنه.
یه ابزاره برای فیلم گرفتن از ترمینال. میشه این فیلم رو توی وبسایت بذاریم که کاربر ببینه یا توی wiki و readme های github/gitlab و حجمش (پهنای باندی که از کاربر مصرف میکنه) در حد هیچیه پس سرعت لود شدنش خیلی بالاست. کیفیتش هم مثل SVG همیشه بالاترین کیفیتیه که مانیتور کاربر میتونه بهش ارائه بده. چون ویدیو نیست که فرقی بین full-hd و qvga داشته باشه. تو هر سایزی بالاترین کیفیته.

پ.ن: موقعی که تصویر داره نشون داده میشه میتونیم یه تیکه از متن رو select و copy کنیم. چون واقعا متن وجود داره نه ویدیو.


#3

روشی که خیلی از سیستم های FRP پیش میگیرند اینکه حالت اول صفحه رو دارند و هر event که شرح تغییر توسط کاربر در زمانه رو در database ذخیره میکنند
به صورتی که با داشتن حالت اول و انجام تمام event ها به حالت آخر میرسند

یک event برای مثال میتونه این شکلی باشه

event_name | user_id | dom_id | created_at
'click'    | 123     |  xyz   | 2019-01-01 20:00:00

#4

خب اینکه ممکنه برای یک برای حرکت موس داخل صفحه به هزاران رکورد در دقیقه برسه… اون روش ذخیره داخل gzip به شکل استریم به نظرم بهتر باشه تا این روش … اینطور نیست ؟


#5

تو سیستم های بزرگ همه event ها به این شکل که نوشتم ذخیره میشه ولی بصورت stream نوشته و خوانده میشه
بعد چند صد یا ۱۰۰۰ event جمع همه event ها تبدیل به یک event میشه که در حجم ذخیره کمک کنه به این snapshot گفته میشه

به عقیده من استفاده از timeseries database روش بهتری از gzip هستش

https://eventstore.org/

https://www.timescale.com/

https://prometheus.io/

کافکا هم گزینه خوبی برای اینکار اما اگر میخواهی داده رو برای بلند مدت حفظ کنی باید یک process داشته باشی که داده کافکا رو در یک database ذخیره کنه


#6

بسیار عالی خیلی ممنون اطلاعات خوبی بود …


#7

یه مطلب دیگه هم الآن به ذهنم رسید.
یه روش مشابه این وجود داره تو صنعت فیلم سازی. یه جورایی immutable ویرایشها رو انجام میدن. به این صورت که فایل پروژشون به دو قسمت «فایل خام» و «مراحل ویرایش» ذخیره میشه. اینطوری هر زمان که بخوان میتونن خروجی نهایی رو ببینن و یا یک سال بعد از تموم شدن تدوین، برن سراغ «مراحل ویرایش» و فلان مرحله رو یه کم تغییر بدن و یه خروجی دیگه بگیرن.
میدونم خیلی خوب توضیح ندادم. اطلاعات کافی هم از این روش کار ندارم. فقط به نظرم رسید بهتره این مطلب رو بگم.

پ.ن: «فایل خام» درمورد کار ما میتونه عکسها و فایل صوتی کسی که توضیح میده باشه و «مراحل ویرایش» میتونه رکورد موس و کیبورد طرف باشه.