Tech

1. DSA

1.1. self balanced trees

1.1.1. avl

1.1.2. btree

1.2. graph

1.2.1. matrix or list

1.2.1.1. for dense graph use matrix otherwise use list

1.3. data structure

1.3.1. array

1.3.1.1. lookup **by index:** o(1)

1.3.1.1.1. fixed sized memory allocation

1.3.1.2. insert: o(n)

1.3.1.2.1. expanding

1.3.1.3. delete: o(n)

1.3.1.3.1. shifting

1.3.1.4. for fixed size list is sutible

1.3.2. linked list

1.3.2.1. lookup: o(n)

1.3.2.2. insert: o(n)

1.3.2.2.1. except inserting at first or last

1.3.2.3. delete: o(n)

1.3.2.3.1. except the first

1.3.2.4. common questions

1.3.2.4.1. reverse

1.3.2.4.2. kth from the end inplace

1.3.2.4.3. find the middle

1.3.2.4.4. find a loop

1.3.3. stack

1.3.3.1. common questions

1.3.3.1.1. arithmetic expression

1.3.3.1.2. undo

1.3.3.1.3. reverse strings

1.3.3.1.4. balanced expression

1.3.3.1.5. Implement two stacks in one array (from start and end)

1.3.3.1.6. MinStack

1.3.3.2. LIFO

1.3.3.3. push: o(1)

1.3.3.4. pop: o(1)

1.3.4. queue

1.3.4.1. implemented using

1.3.4.1.1. array (2 pointers)

1.3.4.1.2. two stacks

1.3.4.1.3. linked list

1.3.4.2. priority queue

1.3.4.2.1. array: start from last and relpacing

1.3.4.3. LinkedListQueue

1.3.4.3.1. newItem => q2 prevItems(q1) => q2 q2 <=> q1

1.3.4.4. FIFO

1.3.5. dictionary

1.3.5.1. hash function is determinestic

1.3.5.1.1. put value in an array index which is numeric representation of the dictionary key

1.3.5.1.2. in case of collision

1.3.5.2. common questions

1.3.5.2.1. find first non repeated char

1.3.5.2.2. unique pairs of integers that have difference k

1.3.6. trees

1.3.6.1. usages

1.3.6.1.1. auto completion

1.3.6.1.2. database index

1.3.6.1.3. compression

1.3.6.2. binary trees

1.3.6.2.1. common questions

1.3.6.3. self balanced trees

1.3.6.3.1. avl

1.3.6.3.2. btree

1.3.6.3.3. red black trees

1.3.6.3.4. splay trees

1.3.6.3.5. 2-3 trees

1.3.6.4. perfect trees (balanced trees)

1.3.6.4.1. the hight diff between of left and right each node is less than or equal to 1

1.3.6.4.2. height formula

1.3.6.5. heap

1.3.6.5.1. properties

1.3.6.5.2. usages

1.3.6.5.3. implementation

1.3.6.5.4. time complexity

1.3.6.5.5. interview question

1.4. algorithem

1.4.1. sorting

1.4.1.1. Patience Sorting

1.4.1.1.1. دونه دونه از چپ شروع میکنی و کارت ها رو به صورت ستونی میچینی

1.4.1.1.2. شرط چینش اینکه که هر کارت باید از کارت بالاییش کوچیکتر باشه

1.4.1.1.3. آخرین کارت هر ستون رو نگاه میکنیم و بررسی میکنیم که آیا کارتی که قراره جایگذاری شه از اون کارت کوچیکتره

1.4.1.1.4. اگه ستونی با چنین شرایطی وجود نداشت یه ستون جدید درست میکنی

1.4.1.1.5. وقتی ستونی جدید ایجاد میشه آخرین کارت ستون آخر مارک میشه

1.4.1.1.6. تعداد ستونی که تشکیل شده میشه طول LIS

1.4.1.1.7. در نهایت مارکر ها رو از آخر به اول میخونیم و میشه LIS

1.4.2. تو مسأله ی مرج دو ارایه ی سرت شده که یکیشون از انتها فضای خالی داشت، با روش ۲ pointer از انتها مسأله شد.

2. CDN

2.1. به‌عنوان مثال، وقتی کاربری صفحه‌ای را در اپلیکیشن شما بارگذاری می‌کند، CDN ممکن است فایل‌های تصویری، CSS، یا ویدیوهای آن صفحه را از نزدیک‌ترین سرور به کاربر ارسال کند. اما اطلاعات داینامیک که به‌طور خاص برای هر کاربر یا درخواست تولید می‌شود، مثل داده‌های کاربر از پایگاه داده، معمولاً توسط سرورهای اصلی شما مدیریت می‌شود و در CDN ذخیره نمی‌شود.

2.2. بهبود زمان بارگذاری وب‌سایت

2.3. کاهش هزینه‌های پهنای باند

2.4. افزایش دسترس‌پذیری و پایداری محتوا

3. restful arc

3.1. Do not use verbs in URIs

3.1.1. GET: /books/createNewBook/

3.2. Use plural nouns for resources

3.3. Pay special attention to HTTP status codes

3.4. The HTTP 204 status code, known as “No Content,” means that the server successfully processed the client's request but does not need to return any content

3.5. Do not nest resources

3.5.1. /books?author=Cagan

3.6. Handle trailing slashes gracefully

4. message brokers

4.1. RabbitMQ

4.1.1. انواع exchange

4.1.1.1. direct

4.1.1.1.1. پیام فقط به Queueهایی میره که Routing Key دقیقاً مطابق باشه.

4.1.1.2. topic

4.1.1.2.1. میشه با pattern (مثل order.* یا user.#) پیام‌ها رو مسیریابی کرد.

4.1.1.3. fanout

4.1.1.3.1. پیام رو به همه‌ی Queueهای متصل می‌فرسته (Broadcast).

4.1.1.4. headers

4.1.1.4.1. بر اساس headerهای پیام، مسیریابی میشه.

4.1.2. انواع پترن

4.1.2.1. pub/sub

4.1.2.2. RPC (request/reply)

4.1.2.2.1. correlation_id

4.1.2.3. Work Queues

4.1.2.4. Broadcast

4.1.2.5. P2P (point to point)

4.1.3. وقتی prefetch رو 1 ست کنیم تا وقتی consumer اکنالج نده کیو بهش اجازه ی برداشتن مسیج رو نمیده

4.1.3.1. چطوری میفهمه ورکر هنوز کانسوم نکرده؟

4.1.3.1.1. وقتی یه worker (مصرف‌کننده) به RabbitMQ وصل میشه، از طریق یه channel این کار رو می‌کنه. RabbitMQ می‌دونه که این channel چند تا پیام تحویل گرفته و کدوم‌هاش هنوز ack نشده‌ن.

4.1.4. اجزا

4.1.4.1. producer

4.1.4.1.1. connection

4.1.5. تو RabbitMQ → اگه ۳ سرویس مختلف بخوان همون پیام رو ببینن، باید ۳ تا Queue تعریف کنی و Exchange پیام رو به هر ۳ تا هدایت کنه. تو Kafka → همه اون ۳ سرویس می‌تونن عضو ۳ Consumer Group جدا باشن و بدون تغییر خاصی، پیام رو از همون Topic بخونن.

4.2. redis

4.3. kafka

5. bloom filtering

5.1. مثال متصدی و کتابخونه که هر دفعه مجبوره بره بگرده ببینه هست یا نیست

5.2. اگه بخوایم ترو نگتیومون کم شه میتونیم از هش فانکشن های بیشتر استفاده کنیم و فضا رو هم بیشتر کنیم

5.3. عملیات دیلیت امکان پذیر نیست و باید از روش هایی مثل Cuckoo Filter و Counting Bloom Filter (CBF) (More memory usage) و Stable Bloom Filter (SBF) (داده های قدیمی حذف میشن به صورت دوره ای) استفاده کنیم

6. Why Pass db to Handlers?

6.1. Separation of Concerns: Keep your handlers focused on their task (handling requests), not creating/managing DB connections.

6.2. Reusability: If the handlers take db as a parameter, they can be reused across multiple places or services.

6.3. Testing: You can pass mock db connections for unit tests, making your code easier to test.

6.4. Connection Pooling: Avoid creating a new connection for every request; pass a shared instance.

7. microservices

7.1. ارتباط بین سرویس ها

7.1.1. راه حل

7.1.1.1. grpc

7.1.1.1.1. ارتباط بین میکروسرویسا

7.1.1.1.2. به صورت باینری دیتا رو ذخیره میکنه و space efficient تره

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

7.1.1.2. message brokers

7.2. کشف سرویس

7.2.1. باید بخونم

7.3. تست و مانیتورینگ سخت

7.4. مدیریت دیتا

7.4.1. ترجیحات

7.4.1.1. هر سرویس دیتابیس مستقل خودش رو داشته باش

7.4.2. سازگاری نهایی (Eventual Consistency)

7.4.3. Event Store (ذخیره‌سازی رویدادها)

7.4.3.1. اگر یک سرویس یک رویداد رو از دست بده یا بخواد داده‌هاش رو دوباره همگام کنه، می‌تونه از Event Store همه رویدادهای قدیمی رو دریافت کنه و وضعیت فعلی خودش رو بازسازی کنه.

7.4.4. Reconciliation

7.4.4.1. اگر ناسازگاری داده‌ها شناسایی شد، از بازپرس (Reconciliation) استفاده کنید تا داده‌ها رو با هم مقایسه و اختلافات رو حل کنید.

7.5. چالش ها

7.5.1. بخوایم یه دیتایی رو از چند تا دیتابیس مختلف بگیریم

7.5.1.1. اگر انعطاف‌پذیری بالا می‌خواهید، GraphQL Gateway مناسبه.

7.5.1.1.1. پیچیدگی در پیاده‌سازی Gateway.

7.5.1.1.2. نیاز به طراحی مناسب برای جلوگیری از درخواست‌های سنگین.

7.5.1.2. اگر سیستم شما تعداد زیادی کوئری بین دیتابیس‌ها داره، Data Replication بهترین گزینه هست

7.5.1.2.1. به‌روزرسانی داده‌ها باید هماهنگ باشه.

7.5.1.2.2. هزینه و پیچیدگی برای نگهداری داده‌های تکراری.

7.5.1.3. اگر به دنبال استقلال کامل سرویس‌ها هستید، Orchestration یا Choreography منطقی‌تره.

7.5.1.3.1. افزایش latency (به دلیل فراخوانی چند سرویس).

7.5.1.3.2. نیاز به کد اضافی برای مدیریت ترکیب داده‌ها.

7.5.1.3.3. تو Choreography از request-reply پترن استفاده میکنیم برای اینکه داده ها رو از consumer های مختلف جمع کنیم و در نهایت ترکیبشون میکنیم و برمیگردونیم

7.6. patterns

7.6.1. SAGA

7.6.1.1. برای مدیریت تراکنش‌های توزیع‌شده

7.6.1.2. وقتی یه تراکنش شامل چند سرویس مختلف باشه و بخوای اطمینان پیدا کنی که همه مراحل به درستی انجام می‌شن یا اگه یکی شکست خورد، کل عملیات به حالت قبلی برگرده، از Saga استفاده می‌کنی.

7.6.1.3. دو روش داره

7.6.1.3.1. Orchestration

7.6.1.3.2. Choreography

7.6.2. Composition یا API Gateway

7.6.3. CQRS (Command Query Responsibility Segregation)

7.6.3.1. Read Model & Write Model

7.6.3.2. When?

7.6.3.2.1. وقتی تعداد خواندن‌ها خیلی بیشتر از نوشتن‌هاست

7.6.3.2.2. مدل داده‌ای که برای نوشتن طراحی شده، معمولاً برای خواندن کارآمد نیست.

7.6.3.2.3. با جداسازی مدل خواندن، می‌تونی پایگاه داده‌ای بهینه برای کوئری‌ها انتخاب کنی. مثلاً از ElasticSearch برای جستجوی سریع استفاده کنی، درحالی‌که نوشتن‌ها رو روی یک دیتابیس رابطه‌ای انجام می‌دی

7.6.3.2.4. در سیستم‌های پیچیده، جداسازی مسئولیت‌ها باعث ساده‌تر شدن منطق کسب‌وکار می‌شه. چون نیازی نیست در یک بخش هم به خواندن سریع و هم به عملیات نوشتن رسیدگی کنی.

8. چک سام چیه؟

8.1. یه جاهایی نیاز داری فقط مطمئن باشی که داده های دریافتی بدون هیچ کم و کاستی دقیقا همون هایی هستن که باید باشن و فقط همین مثلا میخوایم فایل دانلود کنیم - دیتا بین سرویس های مختلف بفرستیم - بک آپ بگیریم ولی اگه بخوای امنیت رو رعایت کنی که مثلا کسی نیومده باشه داده رو دستکاری کرده باشه باید از رمزنگاری استفاده کنی (public key private key) روش هایی که داره مثل بیت پرایتی که میگه مثلا تعداد بیت ها باید فرد باشه یکی اضافه میکنیم و ... در کل این روش زیاد کارامد نیست و برای تغییرات چند بیتی جالب نیست همون md5 کنیم و ... بهتره

9. system design

9.1. lsm-tree

9.1.1. Log Structured Merge Table

9.1.2. یه نوع داده ساختاره که تو دیتابیسایی که برای write heavy طراحی شدن استفاده میشه

9.1.3. از چند بخش تشکیل شده

9.1.3.1. memtable (حافظه موقت)

9.1.3.1.1. برای نوشتن استفاده میشه و بعد اینکه ظرفیتش پر شد به شکل سگمنت جدید روی sstable نوشته میشه

9.1.3.1.2. برای خوندن استفاده میشه و اگه پیدا نشد توی sstable دنبالش میگردیم

9.1.3.1.3. از ساختمان داده ی red-black tree استفاده میکنه

9.1.3.2. sstable (حافظه ی دیسک)

9.1.3.2.1. Sorted String Table

9.1.3.2.2. برای خوندن استفاده میشه وقتی که توی memtable نباشه و از آخرین سگمنت شروع میکنیم

9.1.3.2.3. چند تا سگمنت داره

9.1.3.2.4. اگه داده ای پاک شه روی آخرین سگمنت مقدار کلید رو null ذخیره میکنیم و هنگام جستجو متوجه میشیم که این مقدار وجود نداره.

9.1.4. چون write رو روی مموری انجام میده برای نوشتن سریعه

9.1.5. برای سریع تر کردن جستوجو میتونیم از bloom فیلترینگ هم استفاده کنیم

9.1.6. کاساندرا (فیسبوک) و بیگ تیبل (گوگل) ازش استفاده میکنن

9.2. b-tree

9.2.1. هم sql و هم no-sql

9.2.2. read heavy

9.2.3. متوازنه و ارتفاع درخت log n هست

9.2.4. هر گره میتونه تعداد زیادی فرزند داره و هر گره مقدار زیادی مقدار داره

9.2.5. . [30 | 50 | 70] / | | \ [9 | 10 | 20] [31 | 39 | 40] [51 | 59 | 60] [71 | 79 | 81 | 90] / | \ / | \ / | \ / \ [1] [11,19] [21,29] [31] [39] [41,49] [51] [59] [61,69] [71,79] [81,100]

9.2.6. b+tree [30 | 50 | 70] / | | \ [10 | 20] [40] [60] [80 | 90] / | \ / \ / \ / | \ [1,9] [10,11,19] [20,21,29] [30,31,39] [40,41,49] [50,51,59] [60,61,69] [70,71,79] [80,81,100] برگ‌ها به صورت پیوندی: [1,9] <-> [10,11,19] <-> [20,21,29] <-> [30,31,39] <-> [40,41,49] <-> [50,51,59] <-> [60,61,69] <-> [70,71,79] <-> [80,81,100]

9.3. file system

9.3.1. یه دیسک در نظر بگیر

9.3.2. به حلقه ها میگن track

9.3.3. به اسلایس ها میگن sector

9.3.4. به تقاطع ترک و سکتور میگن بلاک

9.3.5. آدرس هر دیتا با توجه به شماره ی سکتور و ترک روی هر بلاک مشخص میشه

9.4. معماری serverless

10. cache

10.1. کی از دیستریبیوتد کش استفاده می‌کنیم

10.1.1. زمانی که سیستم خیلی بزرگه

10.1.2. زمانی که فالت تالرنس داشته باشیم یعنی اگه یکی از سرورامون از کار افتاد بقیه به کارشون ادامه بدن

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

10.2. چه زمانی از co located کش سرور استفاده می‌کنیم

10.2.1. زمانی که می‌خوایم تو هزینه هامون صرفه‌جویی کنیم

10.2.2. زمانی که سیستم ما کوچیکه و و میشه با انجام دادن این کار low latency داشته باشیم

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

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

10.4. ممکش فیچر خاصی نداره و صرفاً برای کش کردن اطلاعات کاربرد داره و خب به تبعش سبکه

10.5. برای اینکه از ارسال ریکوست های پرشمار به دیتابیس در هنگام cold state جلوی گیری کنیم چه راه هایی داریم؟

10.5.1. mutex

10.5.2. سمافور

10.5.2.1. مکانیزمی که تضمین میکنه در لحظه تعداد معینی ریکوست از یک منبع استفاده میشه (با استفاده از chan)

10.6. استراتژی حذف

10.6.1. LFU (Least frequently used)

10.6.1.1. gboard

10.6.2. LRU (least recently used)

10.6.3. LIFO

10.7. ۸۰ درصد ترافیک روی ۲۰ درصد صفحاته

10.8. چطوری کش کنیم؟

10.8.1. به مساله به شکل کامپوننتی نگاه کنیم

10.8.1.1. کامپوننت a داره از کامپوننت های x,y استفاده میکنه

10.8.1.2. کامپوننت x داره از کامپوننت m,n استفاده میکنه

10.8.1.3. کامپوننت n یه سری اطلاعات دیتابیس رو داره

10.8.1.4. همه اینا رو جدا جدا کش میکنیم تا اگه یه جا اون اطلاعات دیتابیس تغییر کرد کامپوننت های مختلف که دارن ازش استفاده میکنن دیتای اینولید نشون ندن

11. برخی از اصطلاحات

11.1. floating point error: مشکل ذخیره سازی اعداد اعشاری به صورت باینری در کامپیوتر وقتی پیش میاد که استرینگ رو به فلوت تبدیل میکنی

11.2. ORM: یه روشه که پروگرمر رو از کوئری خام و مستفیم به دیتابیس زدن بی نیاز میکنه

11.2.1. مزایا

11.2.1.1. جلوگیری از sql injection

11.2.1.2. ساده سازی کار با دیتابیس

12. Databases

12.1. RDBMS

12.1.1. پارتیشن کردن

12.1.1.1. کی خوبه ازش استفاده کنیم؟

12.1.1.1.1. وقتی جدولت خیلی بزرگه (مثلاً چند میلیون ردیف) و کوئری‌ها کند شدن.

12.1.1.1.2. وقتی جدول‌ها خیلی بزرگ می‌شن، کوئری زدن بهشون ممکنه کند بشه. با پارتیشن‌بندی، کوئری‌ها فقط روی پارتیشن مرتبط اجرا می‌شن.

12.1.1.1.3. وقتی نیاز داری مرتب داده‌های قدیمی رو پاک یا آرشیو کنی.

12.1.1.1.4. وقتی داده‌ها رو مرتباً تقسیم‌بندی‌شده استفاده می‌کنی (مثلاً بر اساس تاریخ، منطقه جغرافیایی، یا دسته‌بندی محصول).

12.1.1.2. کی خوب نیست؟

12.1.1.2.1. وقتی حجم داده‌هات کمه یا نیاز به پارتیشن‌بندی نداری.

12.1.1.2.2. وقتی اکثر کوئری‌هات روی همه داده‌ها اجرا می‌شه و تقسیم‌بندی بی‌فایده‌ست.

12.1.1.3. مزایا

12.1.1.3.1. اگر جدول سفارشات بر اساس تاریخ پارتیشن‌بندی بشه، وقتی دنبال سفارشات ماه دی می‌گردی، فقط روی پارتیشن دی جستجو می‌شه، نه کل جدول.

12.1.1.3.2. می‌تونی هر پارتیشن رو روی دیسک یا سرور جداگانه قرار بدی تا فشار روی یک سیستم کم بشه.

12.1.1.4. معایب

12.1.1.4.1. اگر کوئری‌ای بزنی که داده رو از چندین پارتیشن بخواد، ممکنه کندتر از یک جدول ساده بشه.

12.1.1.4.2. نیاز به آپدیت کردن داره که البته با اسکجولر میشه هندلش کرد

12.1.2. data types

12.1.2.1. blob

12.1.2.1.1. اگه بخوای فایل رو تو دیتابیس ذخیره کنی

12.1.2.2. CHAR vs VARCHAR

12.1.2.2.1. CHAR 255 VARCHAR 4000

12.1.2.2.2. CHAR is faster than VARCHAR.

12.1.2.2.3. طول ثابت: یعنی اگر شما یک فیلد CHAR(10) تعریف کنید، حتی اگر فقط 5 کاراکتر وارد کنید، MySQL بقیه فضا را با فاصله (Space) پر می‌کند. به عنوان مثال، مقدار Hello در یک فیلد CHAR(10) به صورت Hello ذخیره می‌شود. کاربرد: مناسب برای داده‌هایی که همیشه طول ثابتی دارند، مانند کدهای پستی، کدهای کشور یا کدهای محصول.

12.1.2.2.4. طول متغیر: یعنی اگر شما یک فیلد VARCHAR(10) تعریف کنید و 5 کاراکتر وارد کنید، MySQL فقط 5 کاراکتر را ذخیره می‌کند و بقیه فضا را اشغال نمی‌کند. به عنوان مثال، مقدار Hello در یک فیلد VARCHAR(10) دقیقاً به صورت Hello ذخیره می‌شود. کاربرد: مناسب برای داده‌هایی که طول آن‌ها متغیر است، مانند نام‌ها، توضیحات، آدرس‌ها و مواردی که اندازه‌اشان می‌تواند متفاوت باشد.

12.1.2.3. byte < short < int < long (تا اینجا صحیح) < float < double < decmial < big decimal

12.1.3. normalization vs denormalization

12.1.3.1. یه جاهایی حتی میشه 1nf رو هم نقض کرد و از set استفاده کرد و همه ی اینا با توجه به شرایطه که تصمیم میگیری چیکار کنی

12.1.4. **Constraints** are the rules that we can apply to the type of data in a table. NOT NULL - UNIQUE - PRIMARY KEY - FOREIGN KEY - CHECK - DEFAULT

12.1.5. برای انجام عملیات زمانبندی‌شده می‌توانید از CREATE EVENT استفاده کنید:

12.1.5.1. CREATE EVENT my_event ON SCHEDULE EVERY 1 DAY DO INSERT INTO log_table (log_message) VALUES ('Daily log');

12.1.6. Stored Procedures

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

12.1.6.2. هر بار که اجرا می‌شوند، نیازی به کامپایل مجدد ندارند، بنابراین زمان اجرای آنها سریع‌تر است.

12.1.7. کش کردن کوئری تو نسخه ی 8 به بعد حذف شده

12.1.8. Data Integrity

12.1.8.1. فرض کنید یک پایگاه داده فروشگاه آنلاین دارید. اگر مشتری سفارشی ثبت کند

12.1.8.1.1. مشتری در جدول مشتریان وجود داشته باشد (Referential Integrity).

12.1.8.1.2. شماره سفارش یکتا باشد (Entity Integrity).

12.1.8.1.3. مبلغ سفارش عدد مثبت باشد (Domain Integrity).

12.1.8.1.4. فیلدهای ضروری مانند نام مشتری یا آدرس خالی نباشد(Completeness).

12.1.9. sql injection => SELECT * FROM users WHERE username = '' OR '1'='1';

12.1.10. index

12.1.10.1. WHERE، JOIN، ORDER BY و GROUP BY

12.1.10.2. cardinality (مقدایر یکتا) بالا

12.1.10.3. ایندکس روی ستون‌هایی با مقادیر کوچک‌تر (مثل INT یا VARCHAR(20)) سریع‌تر و بهینه‌تر از TEXT یا BLOB است.

12.1.10.4. حواسمون به فارن کی باشه که تو inodb ایندکس میشه ولی تو پستگرس نه

12.1.10.5. یه جایی فول تکست ایندکس مناسبه که از Inverted Index استفاده میکنه که کلمه های داکیومنت رو جدا میکنه و میگه هر کلمه تو چه داکیومنت هایی ذخیره شده

12.1.10.6. انواع

12.1.10.6.1. B-TREE

12.1.10.6.2. HASH

12.1.10.6.3. FULLTEXT

12.1.10.6.4. SPATIAL Index

12.1.10.6.5. UNIQUE

12.1.10.6.6. cover

12.1.10.6.7. COMPOSITE

12.1.10.6.8. GIN و GiST Index

12.1.10.6.9. تصمیم گیری در خصوص ایندکس به نحوه ی استفاده از table مرتبطه و باید ببینیم چه کوئری هایی زده میشه و چه اوپریشن هایی داریم، همچنین میزان اوپریشن رایت و رید هم مهمه

12.1.11. Explain Analyse

12.1.11.1. دستور رو اجرا میکنه

12.1.11.2. از داخلی ترین شروع میکنیم

12.1.11.3. query planner

12.2. normalization

12.2.1. 1nf

12.2.1.1. هر جدول باید یک مقدار در هر سلول داشته باشد

12.2.2. 2nf

12.2.2.1. همه ستون‌های غیرکلیدی باید به کل کلید اصلی وابسته باشند، نه بخشی از آن.

12.2.2.1.1. اگر یک جدول فاکتور از دو ستون "شماره فاکتور" و "کد محصول" به عنوان کلید اصلی استفاده کند، اما "نام مشتری" فقط به شماره فاکتور وابسته باشد، این نقض ۲NF است.

12.2.3. 3nf

12.2.3.1. هیچ ستون غیرکلیدی نباید به یک ستون غیرکلیدی دیگر وابسته باشد

12.2.3.1.1. اگر یک جدول شامل "کد مشتری"، "نام مشتری" و "آدرس مشتری" باشد، اما "آدرس مشتری" به "نام مشتری" وابسته باشد، این نقض ۳NF است.

12.2.4. 4nf

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

12.2.4.1.1. دانشجو دوره مهارت علی ریاضی جاوا علی ریاضی پایتون

12.2.4.2. ۴NF: اگر یک جدول شامل دو مجموعه داده مستقل باشد که به هم ربطی ندارند، آن را به دو جدول جدا تقسیم کن.

12.2.5. 5nf

12.2.5.1. ۵NF: اگر یک جدول را می‌توان بدون از دست دادن اطلاعات به چند جدول کوچک‌تر تقسیم کرد، این کار را انجام بده.

12.3. SQL

12.3.1. isolation levels

12.3.1.1. READ UNCOMMITTED

12.3.1.2. READ COMMITTED

12.3.1.2.1. ترنزکشن دوم تغییرات رو بعد از کامیت شدن میبینه

12.3.1.3. REPEATABLE-READ

12.3.1.3.1. ترنزکشن دوم تغییرات رو نمیبینه حتی اگه ترنزکشن اول کامیت شه

12.3.1.4. SERIALIZABLE

12.3.1.4.1. وقتی دو تا ترنزشکن باز میشن و یکیشون بخواد آپدیت کنه صبر میکنه تا بعدی کامیت شه بعد این کارش رو انجام بده وقتی یه ترنزکشن باز شده و یه تغییراتی میده ولی کامیت نمیکنه ترنزکشن بعدی تو select هم waiting میمونه

12.3.2. WITH RECURSIVE

12.3.2.1. پیدا کردن همه مسیرها از A به شهرهای دیگر.

12.3.2.2. **WITH RECURSIVE** FOO AS ( SELECT ... WHERE City = 'A' UNION ALL SELECT ... JOIN **FOO **... )

12.3.2.3. می‌خواهیم تمامی زیرمجموعه‌های یک مدیر خاص را پیدا کنیم.

12.3.3. diff beween ‘_’ and ‘%’

12.3.3.1. _ : جایگزین یک کاراکتر تکی است.

12.3.3.2. % : جایگزین صفر یا بیشتر از صفر کاراکتر است.

12.3.4. t1:a,a,a,b,b,d t2:a,a,b,z intersect: a,b intersect-all: a,a,b except: d except-all: a,b,d

12.3.5. delete شرط میگیره ولی truncate نه

12.3.6. INTERSECT وجه مشترک رو میاره

12.3.7. اگه بخوای یه تیبل رو کپی کنی create like میکنیش

12.3.8. Union تکراری ها رو حذف میکنه ولی وقتی Union All میزنی تکراری ها رو هم میاره

12.3.9. window functions

12.3.9.1. similar to an agg func, it performs the ops acrross multiple rows. Unlike an agg func, it doesn't group rows into one single row.

12.3.9.2. FUNCTION() OVER (PARTITION BY column ORDER BY column)

12.3.9.3. SELECT window_function() over (window_nane) FROM ... [HAVING ...] WINDOW window_nane AS (PARTITION BY column ORDER BY column) [ORDER BY ...]

12.3.9.4. we want to compare each product's price with the avg price of that year

12.3.9.5. ROW_NUMBER: پیدا کردن سه حقوق برتر در هر دپارتمان. DENSE_RANK, RANK: رتبه‌بندی فروش در هر منطقه - رتبه‌بندی دانش‌آموزان در یک کلاس SUM: محاسبه جمع کل برای هر گروه AVG: محاسبه میانگین مقادیر برای هر گروه COUNT: تعداد کارمندان در هر دپارتمان LAG: مقایسه یک مقدار با مقدار قبلی - بررسی تغییرات فروش نسبت به ماه قبل LEAD: مقایسه یک مقدار با مقدار بعدی CUMULATIVE SUM (SUM با Frame): جمع تجمعی فروش در هر ماه FIRST_VALUE - LAST_VALUE: پیدا کردن حداقل و حداکثر مقدار - حقوق حداقل و حداکثر در هر دپارتمان CUME_DIST - NTILE - PERCENT_RANK هم برای محاسبات آماری پیشرفتن تفاوت بین ROW_NUMBER() و RANK(): تابع ROW_NUMBER() یک شماره ردیف منحصر به فرد برای هر رکورد در مجموعه نتیجه برمی‌گرداند، اما RANK() رکوردهای مساوی را با همان رتبه رده‌بندی می‌کند و بعد از آن رتبه‌ها را می‌پریزد.

12.4. No Sql Databases

12.5. تفاوت ها

12.5.1. mysql

12.5.1.1. بیشتر برای اپلیکیشن‌های وب سبک/متوسط انتخاب می‌شود

12.5.2. postgresql

12.5.2.1. queryهای پیچیده

12.5.2.2. تراکنش ها دقیق

12.5.2.3. برای سیستم‌های مالی، تحلیلی، GIS، و پروژه‌های enterprise-level

12.5.3. mariadb

12.5.3.1. cache query

12.5.4. sqlite

12.5.5. چرا دیسکورد از مونگو سوییج کرد رو کاساندرا؟

12.5.5.1. کاساندرا رایت هویه

12.5.5.2. کاساندرا راحت تر اسکیل اوت میشه چون با کانسیستنت هشینگ ساخته شده در حالی که مونگو روی rebalanceing که برای شاردینگ انجام میشه اذیت میکنه

13. redis

13.1. usages

13.1.1. autocompletion

13.1.2. vector databases

13.1.3. various data structures like geo locations

13.1.4. single core

13.1.5. global lock

13.1.5.1. فروش محصول

13.2. cons

13.2.1. limitation

13.2.1.1. ram is expensive

13.3. types

13.3.1. string

13.3.1.1. SET x y

13.3.1.1.1. SET user:13:name ali

13.3.1.2. GET x

13.3.1.3. INCRBY x -3

13.3.1.4. GETSET x

13.3.1.4.1. برای گلوبال لاک

13.3.1.5. به جای get set بهتره mget و mset بزنی که نتورک لیتنسی ریسپانس تایم رو کم نکنه

13.3.1.5.1. MGET x x1 x2

13.3.1.5.2. MSET x y x1 y1 x2 y2

13.3.2. hash

13.3.2.1. HSET x name foo age 21

13.3.2.2. get

13.3.2.2.1. HGET x name

13.3.2.2.2. HGETALL x

13.3.2.2.3. HMGET xx name age

13.3.3. set

13.3.3.1. SADD meat berger kabab pizza SADD irani kabab jujeh

13.3.3.2. SISMEMBER irani jujeh

13.3.3.2.1. o(1)

13.3.3.3. SMEMBERS irani

13.3.3.4. SINTER irani meat kabab

13.3.4. list

13.3.4.1. جای ربیت و کافکا

13.3.4.1.1. Blpop

13.3.4.2. LPUSH x 1 2 3 4

13.3.4.3. LRANGE x 0 -1

13.3.4.4. queue

13.3.4.4.1. lpush rpop

13.3.4.5. stack

13.3.4.5.1. lpush lpop

13.3.5. sorted set

13.3.5.1. ستی که میشه به آیتم هاش وزن داد

13.3.5.2. ZADD x 4 ali 2 reza 3 hasan

13.3.5.3. ZRANGE x 0 2

13.3.5.3.1. reza, hasan

13.3.5.4. ZREVANGE x 0 2

13.3.5.4.1. ali, hasan

13.3.5.5. leaderboard

13.3.5.5.1. o(n)

13.3.5.6. آیتم ها تو کتگوری های مختلف وزن/امتیاز/نمره ی مختلف دارن

13.3.5.6.1. ما میگیم آیتم هایی که تو کتگوری های مشخص شده ی ما در مجموع امتیاز بهتری/بدتری دارن کدومان

13.3.5.7. مثلا میخوایم جاب کاربری که سابسکرایب کرده زودتر انجام شه

13.3.6. streaming

13.3.6.1. XADD ,...

14. click house

14.1. column based

14.1.1. نیاز نیست ستون هایی که نیاز نداره رو تو مموریش نگه داره

14.2. space efficient

14.2.1. using comperssion

14.3. primary index

14.3.1. می‌شه گفت پرایمری ایندکس توی ClickHouse شبیه پرایمری ایندکس توی RDBMS هست، با این تفاوت که به‌جای ایندکس‌کردن رکورد به رکورد، روی مجموعه‌ای از رکوردها (بلوک‌ها یا granuleها) ایندکس می‌سازه.

14.4. sparse index

14.4.1. از هر بلوک، یه رکورد نماینده (مثلاً مینیمم کلید) رو ایندکس می‌کنه تا بفهمه اون بلوک به درد query می‌خوره یا نه.

14.5. skip index

14.5.1. Skip index معمولاً خلاصه‌ای (summary) از مقادیر هر بلوک داده نگه می‌داره. مثلاً: min، max، یا یه Bloom filter از مقادیر ستون.

14.6. vectorized exection

14.6.1. ستون رو میشکنه و با چند تا پروسسور کارشو انجام بده

15. انواع دیپلویمنت

15.1. canary deployment

15.1.1. تعداد کمی از کاربران به صورت تدریجی.

15.2. green blue deployment

15.2.1. تمام کاربران به یکباره پس از سوئیچ.