فى ال podcast عن كافكا اتكلمنا عن مفهوم فى ال replication وهو ال High water mark
فالثريد دى هتكلم شوية عن المفهوم دا فخلينى اتكلم شوية عن المشكلة هو احنا ايه المشكلة الى بنحاول نعالجها .
فى ال write a head log ودا باترن بنستخدمه عشان نعمل recovery لل consistent state بعد ما السيرفر يرجع من ال crash ممكن تقرأ شوية تفاصيل عنه فى الثريد دى

https://twitter.com/rgbdev/status/1618274700324638724

إستكمالا للكلام عن ال WAL وفى Postgres على وجه الخصوص خلينا نقول ان ال WAL structure بينقسم الى نوعين logical و physical هتكلم الأول عن ال logical لو بنتكلم logical نقدر نقول عن ال WAL انه stream of log entries مسبوق ب header ال header دا فيه بعض المعلومات ودا بيكون standard يعنى اى كان ال log entry طيب ال header دا فيه المعلومات الأتية
- transaction id related to the entry
- the resource manager المسؤول عن ترجمة كل entry
- the checksum ودى عشان اقدر امسك تلف البيانات
- entry length
- reference ل entry السابق

عن ال data integrity فى الأنظمة الموزعة وال stream processing وأشياء أخرى
لما يكون عندنا داتا ستور واحدة فى السيستم غالبا مشاكل ال concurrency مبتبئاش ضيف عندنا لكن تخيل لو شغالين على نظام موزع اكتر من داتا ستور معانا محتاجين ن replicate فيهم البيانات وطبعا ممكن يكونوا مختلفين النوع SQL , index , cache فى ال distributed system ال ACID والحاجات الجميلة دى مش معانا لان عندنا اكتر من behavior خارج عن الابلكشن بتاعنا زى
Network , Node , Clock (time behavior)
كل دى عوائق هتقابلنا هتتحكم فى ال trade offs مابين CAP

عن ال consistency وال concurrency اغلب التطبيقات التجارية لما بيكون الأركتكتشر المسيطر هو three-tier (client -server - database) وبيكون عندنا خصائص ال ACID
الظريفة والى قواعد البيانات هى الى بتهندل لنا الconcurrent changes وبتعزل المستخدمين عن طريق الisolation levels الى بتمكنا من ال strong consistency وكل الناس تقدر تشوف نفس الشئ فى اى وقت بدون اى اختلاف بفضل ال monolithic وال ACID properties لكن لما طبيعة الأبلكشن والتحديات تخلينا نقلب ال monolithic دا لمجموعة من ال distributed services هنا مش بتكلم تحديدا عن الميكروسيرفسس لكن بتكلم عامة

ادارة ال Config فى ال Kubernetes او ال environment بشكل عام ال gitops حط لها شوية properties مهمة زى
- Declarative
- Readable
- Flexible
- Maintainable
فيه ادوات كتير اقدر اهندل بيها ال environment isolation وال changes على مستوى ال manifest اشهرهم فى ال cloud native زى الhelm وانا بصراحة بشوف package manager لل K8s اكتر منه environment configuration management لكن تقدر تستخدمه للغرض دا بردوا هو فى النهاية template ,parameter driven بيديك template very flexible وتقدر تباصى ال parameters values من yaml file

This is not accurate, we can not assume that database system CA or CP if we talking about the official definition of CAP theorem exactly we can consider consistency anything that fit our trade-offs but if we talk about theory we should follow the exact definition C in CAP mean linearlizability that means operation B started after operation A successfully completed, then operation B must see the the system in the same state as it was on completion of operation A, or a newer state

مراجعة كتاب gitops الفصل الثامن والاخير
فى الجزء الثانى (Observability)
فى الفصل دا الكتاب بيتكلم عن اخر عمود فى أعمدة ال gitops وهو أن تكون ال Observability enabled ، بدأ الكتاب يدى انترو سريعة عن ال Observability لانه الكتاب مش متخصص فى الجزء دا واتكلم عن أعمدة ال Observability ال tracing , event logging , Metrics وازاى نعمل الكلام دا فى Kubernetes فى البداية بشكل بدائى مبسط زى انك تطلع ال top nodes أو ال top pods وتراقب استهلاك ال resources بعد كدا اتكلم عن أدوات ال Observability إلى منها Prometheus وال time series

مراجعة كتاب gitops الفصل السابع Secrets
استكمالا لل security الفصل دا بيتكلم عن ال Secrets management فى ال Kubernetes الكتاب بدأ يتكلم عن أهمية secrets زى مثلا ال connection string لل production db متكونش متاحة لل humans readable للناس إلى ملهاش صلاحية تشوف الكلام دا أو انك مثلا تستخدم env variable تحط فيه معلومات زى connection string أو private key الخ فوضح الكتاب استخدام Kubernetes secrets إلى تقدر تعمل لها reference فى ال env أو config map الخ لكن طبعا من خلال ال gitops الكلام دا not recommended عشان lack of security

فى الثريد دا هراجع كتاب GitOps الكتاب مكون من 11 فصل على 3 اجزاء هحاول استعرض كل فصل فى ثريد او كل جزء لكن خلينا فى الاول نتكلم عن نظرة شاملة عن الكتاب بشكل عام الكتاب تقييمى ليها 4 من 5 فهو كتاب جيد طيب الكتاب بيتكلم عن مصطلح GitOps وهو نسخة من ال DevOps لكن بإتجاهات مختلفة مختلفة هتكلم عنها مبدئيا الكتاب مكون من 3 اجزاء على 11 فصل الجزء الأول مكون من فصلين
- بيوضح ايه هو GitOps وليه ممكن يكون مفيد وبياخدك لمقارنة ما بين ال tradational ops , DevOps , gitOps
- بعد كدا بيتكلم عن علاقة ال Gitops ب Kubernetes وازاى لل Gitops بي power ال CloudNative

واحدة من عيوب ال postgres هى أنها مش بتدعم لسه ال loss index scan زى باقى ال engines التانية إلى بتدعم دا زى MySQL فلذلك لل query دا مكلف فى ال postgres
SELECT DISTINCT col FROM tbl;
لأن ال postgres هيعمل btree scan على عكس ال engines التانية إلى هتعمل skip index scan و وهتبدا تعمل scan لكل ال equal values لنفس ال key ومع كل value جديدة هتعيد البحث عن قيمة اكبر ودى عملية اسرع من ال btree scan فلذلك انت ممكن تستخدم. Common table expression عشان توصل لنتيجة مقاربة البرفورمنس بتاع ال skip index لكن الكويرى هيكون شكله أعقد فى الفهم زى كدا

بمناسبة ال challenges إلى بيطرح @AlaaAttya فى الداتا بيس عموما وال postgres خصوصا خلينى cover شوية عشوائيات متعلقة بال performance فى ال internal postgres اول حاجة حابب اتكلم عنها هى ال. RPC ودى مش remote procedure call لا دى حاجة اسمها Random Page cost Ratio دى واحدة من الاعدادات إلى بتؤثر فى سلوك ال planner ودى بتكون مرتبطة بال cost الحاصل لما بيحصل disk access فى حالة المفاضلة بين ال sequential read vs Random read لل value دى ال default بتاعها ٤ ودا رقم كويس لو انا يستخدم mechanical disk عشان كدا زمان مكنش لل ratio دا اهميه كبيرة

ال thread دى هكمل كلام فيها شوية عن ال implementation وازاى تحط الداتا بتاعتك بشكل يساعدك تقدر تستخدمها بسهولة ، خلاص انت قررت تستخدم كافكا وعارف هتعمل ايه تعالى بئا نشوف حكاية ال implementation اول حاجة كدا kafka does not support ordering across partitions طيب ايه حكاية ال ال partition وليه انا محتاج اخلى ال topic يكون له اكتر من بارتشن ببساطة البارتشن هيقدر يخليك توزع ال offsets على اكتر من جزء ودا بيخلى ال consumers تقدر تسحب الداتا parallel يعنى لو عندك توبيك عليه 3 بارتشن تقدر تقوم 3 consumer instances جوا group فى حالة دى هتقدر تسحب الداتا من

ثريد عن كافكا عشان الناس إلى بتستعمله عمال على بطال
مبدئيا هل انت محتاج كافكا ؟
عشان تجاوب على السؤال دا اعرف كافكا شغال ازاى ناس كتير جدا بتخلط ما بين كافكا وما بين كافكا كلاينتس ال clients بتختلف من لغة التانية مثال فى nodejs عاملين event driven client بحيث أنه ليظهر قدامك أن كافكا دا شغال subscribers ودا مش حقيقى كافكا consumer / producer يعنى انت كل شوية بتعمل poll عشان تشوف فيه مسج تخصك ولا لأ بناءا على ال consumer group بتاعك فلو فاكر أن كافكا pub / sub فانت كدا مذاكر lib معينة مش كافكا ، طيب كافكا event streaming ودا مفهوم مختلف شوية عن ال MQ