Aman world

IT-ға қатысы жоқ адамға қалай оқылады екен мына тарау 😐

Бүгін шетелге көшкеніме тура 7 жыл болыпты... Бір кішігірім шабаданмен көшіп кете салдық қой...

Бүгін менеджерімнің менеджерімен 1:1 болды. 1:1 дегенге төбелесті екен деп ойлап жүрмеңіздер. Жай митинг қой бетпе-бет сөйлесетін. Митинг дегенге шеру деп ойлап қалмаңыздар, жай жиналыс қой 😁 Сол 1:1ға дайындалып бардым, сұрақтарымды жинақтап. Сұрақтарым келесе левелге жету үшін қалай жұмыс істеу керек деген сияқты болды. Керемет жауаптар алдым. Өте көп инсайттар алдым. Сіз де инсайттар естіп, карьераңызды келесі деңгейге көтергіңіз келсе менің курсыма жазылыңыздар 🤣🤣🤣

SQL vs NoSQL [2-ші бөлім] 💻NoSQL (Not Only SQL): Икемділік пен масштабталу NoSQL дерекқорлары (мысалы, MongoDB, Cassandra, Redis және тб) 2000 жылдаран бері танымал бола бастаған. Олардың басты ерекшеліктері: 📍Икемді құрылым: Деректер әртүрлі форматта сақталуы мүмкін (JSON, key-value, graph, document). 📍Масштабталу: Деректер көлемі өскен сайын жүйені оңай кеңейтуге болады. 💻NoSQL құрылымының әртүрлі түрлері: 📍Key-value: Бұл ең қарапайым NoSQL моделі. Деректер кілт (key) және мән (value) жұптары түрінде сақталады. Мысалы, Redis осы модельді қолданады және кэштеу, сессияларды сақтау сияқты тапсырмаларға өте ыңғайлы. Қысқаша айтқанда қарапайым Map сияқты жұмыс істейді. -->Find user with id 12345 -->GET user:12345 📍Document: Құжаттар (documents) түрінде сақталады. Әр құжат өзіндік бірегей идентификаторға (ID) ие және құрылымы бойынша еркін болуы мүмкін. MongoDB ең танымал document-oriented NoSQL дерекқоры болып табылады. Онда JSON форматында сақталады -->Жасы 30-дан асқан юзерлердің барлығын шығарып береді. -->db.users.find({ age: { $gt: 30 } }); 📍Graph: Деректер түйіндер (nodes) және олардың арасындағы байланыстар (relationships) түрінде сақталады. Бұл модель әлеуметтік желілердегі байланыстарды, ұсыныстар жүйелерін немесе басқа да күрделі байланыстарды модельдеу үшін өте пайдалы. Neo4j графтық дерекқорларға мысал бола алады. -->Node: User1 Properties: name: "Баке" -->Node: User2 Properties: name: "Саке" -->Relationship: User1 FOLLOWS User2. -->Баке фолоу жасайтын барлық юзерлерді табу: -->MATCH (user:User {name: "Баке"})-[:FOLLOWS]->(otherUser:User) RETURN otherUser.name 📍Wide-column: Деректер бағандар (columns) бойынша сақталады, бірақ әр жолда (row) әртүрлі бағандар болуы мүмкін. Cassandra осы модельді қолданады, үлкен көлемдегі деректерді талдауға өте ыңғайлы. Қарапайым SQL-ға ұқсайтын тіл қолданылады. Барлығының ішінде ең түсініксіздеуі осы сияқты. Кейінірек түсініктірек қылып толықтырып қоярмын. 💻Қай кезде NoSQL таңдау керек? Әрине мұнда әрбір жағдайды жеке қарастыру қажет. Дегенімен high level айтатын болсақ: 📍Деректер құрылымы жиі өзгеретін болса. Заказчик ананы өзгерт мынаны өзгерт дей беретін болса 🤣 📍Масштабталу маңызды болса. 📍Жоғары өнімділік қажет болса. 💻Қорытынды SQL және NoSQL дерекқорларының екеуінің де өз артықшылықтары мен кемшіліктері бар. Қайсысын таңдау жобаның талаптарына байланысты. Егер сенімділік пен деректердің тұтастығы маңызды болса, SQL таңдаңыз. Егер икемділік пен масштабталу маңызды болса, NoSQL таңдаңыз. Жалпы SQL және NoSQL туралы біліп жүрген абзал, қажет жағдайда қолдана алатындай.

SQL vs NoSQL [1-ші бөлім] Бүгін database әлемінің екі басты тақырыбын талқылаймыз: SQL және NoSQL. Бұл екеуінің арасындағы айырмашылықтарды түсіну және қай кезде қайсысын қолданған дұрыс екенін білу өте маңызды. 💻SQL (Relational Databases): бекем және қатаң SQL дерекқорлары (мысалы, PostgreSQL, MySQL, Oracle және тб) IT әлемінде ұзақ уақыттан бері қолданылып келеді. Олардың басты ерекшеліктері: 📍Құрылымдық: Деректер қатаң кестелерде (таблицаларда) сақталады, ал кестелер өзара кілттер арқылы байланыстар (relationships) орнатады. 📍ACID қасиеттері: Atomicity (атомарлық), Consistency (консистенттілік), Isolation (изоляция), Durability (тұрақтылық) қасиеттері деректердің сенімділігін арттырады. 📍SQL тілі: Деректерді басқару үшін күшті және стандартталған тіл қолданылады. Программист адамға базасын игеріп алу өте оңай. -->Мысал: Айлығы 50000 көп жұмысшылардың есімдерін табу. -->SELECT name FROM employees WHERE salary > 50000 💻Қай кезде SQL таңдау керек? 📍Деректер құрылымы алдын ала белгілі және өзгермейтін болса. 📍Деректердің тұтастығы өте маңызды болса (мысалы, қаржылық транзакциялар болса). 📍Күрделі query/запрос жасау қажет болса.

Систем дизайнға тағы бір пост жазып тастадым. Мен өзіме ыңғайлы болсын деп бірінші гугл докс-қа жазамын. Сосын соны telegram-ға көшіремін. Пост-ты көшіріп телеграмға салып қалсам әріптері өте өте көп пост болып шықты. Ондай long read ешкім оқымайтыны анық (өзім точно оқымас едім 🤣). Текстің кемінде жартысын алып тастау керек бір нәрсе қылып 🙈

Жарайды, сіздерді триггер жасамай ақ қояйын, өшіріп тастадым постты. Көңілдеріңізге алмаңыздар. Одан да өзімнің систем дизайн посттарымды жазып жүре берейін 🙌

Телеграм каналды ашқандағы ең алғашқы ойым осындай болған 😅 Абай атамыз блогер болған ғой негізі. Әрбір қара сөзі қазір инстаграм/телеграмда жеке пост болар еді.

Эххх, систем дизайн туралы посттардан гөрі осы сияқты қысқа посттар реакция көбірек жинайды. Неге екен? Систем дизайн барлығына қызық тақырып емес ау. Менің жаңдайымда backend инженерге ғана қызық болуы мүмкін.

Негізі кодты сен жазбайсың, сенің екі қолың жазады. Сен жай ғана отырасың.