مرحبًا بك في الدرس الثالث ، نمذجة البيانات لقواعد البيانات غير العلائقية.
أهداف التعلم لهذا الدرس هي:
هذا واحد من الموضوعات المفضلة و برغم إنه معقد بعض الشيء ولكنه يكون شيق للغاية بمجرد أن يكون لديك فهم كامل لكيفية القيام بنمذجة البيانات لقواعد بيانات NoSQL.
So, let's just go through some terminology.
لذا ، دعنا ننتقل إلى بعض المصطلحات.
NoSQL and non-relational are interchangeable terms.
NoSQL و non-relational هي مصطلحات قابلة للتبادل.
So, NoSQL equals not only SQL.
لذا ، فإن NoSQL لا تساوي SQL فقط.
For the rest of this lesson,
بالنسبة لبقية هذا الدرس ،
I'll refer to non-relational databases as NoSQL databases.
سأشير إلى قواعد البيانات غير العلائقية كقواعد بيانات NoSQL.
Historically, this did stand for non-SQL or NoSQL.
تاريخيا ، كان هذا يمثل غير SQL أو NoSQL.
But as we learned in lesson one,
ولكن كما تعلمنا في الدرس الأول ،
NoSQL has come to mean not only SQL.
أصبحت NoSQL لا تعني فقط SQL.
As languages like Cassandra query language closely mimics SQL and they're very close.
نظرًا لأن لغات مثل لغة كاساندرا تحاكي لغة SQL عن كثب وهي قريبة جدًا.
So, let's just do a quick refresher on when to use a NoSQL database.
لذلك ، دعونا نجري تحديثًا سريعًا حول وقت استخدام قاعدة بيانات NoSQL.
So, if you need high availability,
لذلك ، إذا كنت بحاجة إلى توفر عالٍ ،
you have large amounts of data.
لديك كميات كبيرة من البيانات.
You need linear scalability.
أنت بحاجة إلى قابلية التوسع الخطية.
You need low latency,
أنت بحاجة إلى زمن انتقال منخفض ،
you need fast reads and writes.
تحتاج إلى قراءة وكتابة سريعة.
For example; if you are going to be using Apache Cassandra,
فمثلا؛ إذا كنت ستستخدم Apache Cassandra ،
that's a good example of when you would use a NoSQL database is to use Apache Cassandra.
هذا مثال جيد على الوقت الذي ستستخدم فيه قاعدة بيانات NoSQL هو استخدام Apache Cassandra.
So, let's talk a little bit about what Apache Cassandra actually is.
لذا ، لنتحدث قليلاً عن ماهية أباتشي كاساندرا في الواقع.
So, it's an open source NoSQL database.
لذلك ، فهي قاعدة بيانات مفتوحة المصدر NoSQL.
You can go download the code right now.
يمكنك الذهاب لتنزيل الكود الآن.
It's all open source and you can go download it, check it out.
كل ذلك مفتوح المصدر ويمكنك تنزيله والتحقق منه.
Run it. Whatever you want do contribute to it. We would all love that.
شغلها. كل ما تريد المساهمة فيه. كلنا نحب ذلك.
It has a masterless architecture and it has high availability.
تتميز بهندسة معمارية لا مثيل لها ولديها توافر كبير.
It's linearly scalable.
إنها قابلة للتطوير خطيًا.
So, like I said Apache Cassandra is an open-source technology that was created
لذا ، كما قلت ، Apache Cassandra هي تقنية مفتوحة المصدر تم إنشاؤها
at Facebook and became a top-level Apache project in 2010.
في Facebook وأصبح مشروع Apache رفيع المستوى في عام 2010.
It was created to handle
تم إنشاؤه للتعامل معها
big data challenges that relational databases were failing to meet.
تحديات البيانات الضخمة التي فشلت قواعد البيانات العلائقية في مواجهتها.
It's a masterless architecture with no single point of
إنها هندسة معمارية لا مثيل لها بدون أي نقطة واحدة
failure which makes it highly available.
مما يجعلها متاحة للغاية.
It has low latency for reads and writes and it's linear scalable.
يتميز بزمن انتقال منخفض للقراءة والكتابة وقابل للتطوير الخطي.
You add more nodes to just a quick note on when I use the term nodes,
أنت تضيف المزيد من العقد إلى مجرد ملاحظة سريعة عندما أستخدم مصطلح العقد ،
we use that a lot in the distributed database world.
نحن نستخدم ذلك كثيرًا في عالم قاعدة البيانات الموزعة.
But it's really a server.
لكنه في الحقيقة خادم.
It can mean server or VM or it's just a system.
يمكن أن تعني الخادم أو VM أو مجرد نظام.
One single entity of that system whatever that a Docker container,
كيان واحد من هذا النظام مهما كانت حاوية Docker ،
whatever that system is that's what it means.
مهما كان هذا النظام فهذا ما يعنيه.
So, when we say nodes that's what we're referring to.
لذلك ، عندما نقول العقد فهذا ما نشير إليه.
So, as you add more nodes to the system,
لذلك ، كلما أضفت المزيد من العقد إلى النظام ،
your performance will actually increase
سيزيد أداءك بالفعل
linearly when you're thinking about linear scalability.
خطيًا عندما تفكر في قابلية التوسع الخطي.
Apache Cassandra is used at the backend for some of those most popular apps.
يتم استخدام Apache Cassandra في الواجهة الخلفية لبعض تلك التطبيقات الأكثر شيوعًا.
Basically, if you take a look at your phone,
في الأساس ، إذا ألقيت نظرة على هاتفك ،
some of the apps that you use every day,
بعض التطبيقات التي تستخدمها كل يوم ،
Apache Cassandra is the backend.
أباتشي كاساندرا هي الواجهة الخلفية.
So, very popular apps that use Apache Cassandra are Uber,
لذا ، فإن التطبيقات الشائعة جدًا التي تستخدم Apache Cassandra هي Uber ،
Netflix, Hulu, and Twitter.
نتفليكس وهولو وتويتر.
Those are just a few. Another example is Apple.
هؤلاء مجرد قلة. مثال آخر هو شركة آبل.
Apple has over a 7,000 node deployment of Apache Cassandra.
تمتلك Apple أكثر من 7000 عملية نشر لعقد Apache Cassandra.
Companies like DataStax, Apple,
شركات مثل DataStax و Apple و
Twitter and Facebook are all major contributors to the project.
يعد كل من Twitter و Facebook من المساهمين الرئيسيين في المشروع.
Remember with an open-source project,
تذكر مع مشروع مفتوح المصدر ،
anyone is free to contribute.
أي شخص حر في المساهمة.
Let's talk of some of the basics of NoSQL database design.لنتحدث عن بعض أساسيات تصميم قاعدة بيانات NoSQL.
So, before I get started I just kind of
لذا ، قبل أن أبدأ أنا فقط نوعًا ما
want to let you know that the reason that we have to do a little
أريد أن أخبرك أن السبب في أننا يجب أن نفعل القليل
bit more on the distributed database design is because the difference in
أكثر قليلاً في تصميم قاعدة البيانات الموزعة لأن الاختلاف في
the design is why our data modelling has to be different than relational databases.
التصميم هو سبب اختلاف نمذجة البيانات لدينا عن قواعد البيانات العلائقية.
So, I just want to focus on that.
لذا ، أريد فقط التركيز على ذلك.
That's why we're talking about some of
لهذا السبب نتحدث عن بعض
these design concepts that we didn't really touch in relational.
مفاهيم التصميم هذه التي لم نلمسها حقًا في العلائقية.
In a distributed database,
في قاعدة بيانات موزعة ،
in order to have high availability you need copies of your data. Let's break that down.
من أجل الحصول على نسبة عالية من التوفر ، تحتاج إلى نسخ من بياناتك. دعونا نكسر ذلك.
First, what is a distributed database?
أولاً ، ما هي قاعدة البيانات الموزعة؟
This is a database that has been scaled out horizontally.
هذه قاعدة بيانات تم تحجيمها أفقيًا.
It's not just a single system but a database made up of multiple machines.
إنه ليس مجرد نظام واحد ولكنه قاعدة بيانات مكونة من أجهزة متعددة.
Second, high availability.
الثانية ، توافر عالية.
This means that my system is always up and there's no downtime
هذا يعني أن نظامي يعمل دائمًا ولا يوجد توقف
or very little downtime but essentially no downtime.
أو فترة نقاهة قليلة جدًا ولكن بدون توقف بشكل أساسي.
That isn't to say that all my nodes are always up because nodes will fail.
هذا لا يعني أن جميع العقد الخاصة بي تعمل دائمًا لأن العقد ستفشل.
It's just the nature of how this works.
إنها فقط طبيعة كيفية عمل هذا.
If you have 7,000 machines running one of them is going to
إذا كان لديك 7000 جهاز يعمل على تشغيل واحد منهم
fail and because the nodes will fail,
تفشل ولأن العقد ستفشل ،
that node will go down.
سوف تنخفض هذه العقدة.
Third, if my system is distributed and my nodes will go down,
ثالثًا ، إذا تم توزيع نظامي وستنخفض العقد الخاصة بي ،
this means I need copies of my data.
هذا يعني أنني بحاجة إلى نسخ من بياناتي.
My data cannot just live in one place.
لا يمكن أن تعيش بياناتي في مكان واحد فقط.
With the fact that my data is copied throughout my system leads to
مع حقيقة أن بياناتي يتم نسخها عبر نظامي يؤدي إلى
the fact that my data may not be up to date in all locations.
حقيقة أن بياناتي قد لا تكون محدثة في جميع المواقع.
This is called eventual consistency.
هذا يسمى الاتساق النهائي.
So, let's talk about what eventual consistency means.
لذا ، لنتحدث عما يعنيه الاتساق النهائي.
A consistency model used in distributed computing to achieve high availability.
نموذج التناسق المستخدم في الحوسبة الموزعة لتحقيق الإتاحة العالية.
That informally guarantees that if no new updates are made to a given data item,
يضمن ذلك بشكل غير رسمي أنه في حالة عدم إجراء تحديثات جديدة لعنصر بيانات معين ،
eventually all access to that item will return the last updated state.
في النهاية ، سيعيد كل الوصول إلى هذا العنصر آخر حالة تم تحديثها.
This is basically saying that over time if
هذا هو في الأساس يقول ذلك مع مرور الوقت إذا
no new changes are made that each copy of my data will be the same.
لم يتم إجراء أي تغييرات جديدة على أن تكون كل نسخة من بياناتي متطابقة.
But this also means that if there are new changes,
ولكن هذا يعني أيضًا أنه إذا كانت هناك تغييرات جديدة ،
the value of my data I should say,
قيمة بياناتي التي يجب أن أقولها ،
maybe different in different locations.
ربما مختلفة في مواقع مختلفة.
Now, many people hear that and are very concerned.
الآن ، كثير من الناس يسمعون ذلك وهم قلقون للغاية.
First and foremost we are talking about
أولا وقبل كل شيء نتحدث عنه
milliseconds that the data may be in fact inconsistent.
ملي ثانية أن البيانات قد تكون في الواقع غير متسقة.
Secondly, there are workarounds to prevent getting stale data that are outside
ثانيًا ، هناك حلول لمنع الحصول على بيانات قديمة موجودة في الخارج
the scope of this course but rest assure they've been put in place to prevent issues.
نطاق هذه الدورة ولكن كن مطمئنًا أنه تم وضعها لمنع المشكلات.
The CAP Theorem. This is a theorem in computer science that
نظرية CAP. هذه نظرية في علوم الكمبيوتر
states it is impossible for distributed data store to
تنص على أنه من المستحيل تخزين البيانات الموزعة ل
simultaneously provide more than two out of the three following guarantees: consistency,
توفر في وقت واحد أكثر من اثنين من الضمانات الثلاثة التالية: الاتساق ،
availability, and partition tolerance.
التوفر والتسامح مع التقسيم.
Consistency. Every read from the database gets
التناسق. كل قراءة من قاعدة البيانات تحصل عليها
the latest and correct piece of data or it gets an error.
أحدث جزء من البيانات الصحيحة أو تحصل على خطأ.
Availability. Every request is received and a response
التوفر. يتم استلام كل طلب والرد عليه
is given without a guarantee that the data is the latest update.
يتم تقديمه دون ضمان أن البيانات هي آخر تحديث.
Partition Tolerance.
التسامح التقسيم.
The system continues to work regardless of losing network connectivity between nodes.
يستمر النظام في العمل بغض النظر عن فقدان اتصال الشبكة بين العقد.
When your system is running fine,
عندما يعمل نظامك بشكل جيد ،
there's no network failures.
لا توجد أعطال في الشبكة.
You can also have availability and consistency.
يمكنك أيضًا الحصول على التوافر والاتساق.
But when the system has network failures,
ولكن عندما يعاني النظام من أعطال في الشبكة ،
then you may only have consistency or availability.
عندها قد يكون لديك الاتساق أو التوافر فقط.
Apache Cassandra and other NoSQL databases
Apache Cassandra وقواعد بيانات NoSQL الأخرى
choose to be highly available at the potential cost of consistency.
اختر أن تكون متاحًا بدرجة عالية بالتكلفة المحتملة للاتساق.
It is an AP (Availability and Partition tolerant) database.
إنها قاعدة بيانات AP (التوافر والتسامح مع التقسيم).
Remember, this only comes up during network failures.
تذكر أن هذا لا يظهر إلا أثناء أعطال الشبكة.
I want to make it clear that we're learning about
أريد أن أوضح أننا نتعلم
these concepts because the difference
هذه المفاهيم بسبب الاختلاف
in the design of NoSQL databases affects how we will model the data.
يؤثر تصميم قواعد بيانات NoSQL على كيفية نمذجة البيانات.
The Importance Of Denormalization in Apache Cassandra.
أهمية عدم التطابق في أباتشي كاساندرا.
Denormalization of tables in Apache Cassandra is absolutely critical.
يعد عدم تسوية الجداول في Apache Cassandra أمرًا بالغ الأهمية.
The biggest take-away when doing data modelling in Apache Cassandra is to
أكبر استفادة عند القيام بنمذجة البيانات في Apache Cassandra هو
think about your queries first. I want to say that again.
فكر في استفساراتك أولاً. اريد ان اقول ذلك مرة اخرى
Think about your queries first.
فكر في استفساراتك أولاً.
There are no joins in Apache Cassandra.
لا توجد صلات في أباتشي كاساندرا.
In relational data modeling,
في نمذجة البيانات العلائقية ،
what worked well for relational database cannot
ما نجح في قاعدة البيانات العلائقية لا يمكنه ذلك
be moved over as is into Apache Cassandra.
يتم نقلها كما هو الحال في أباتشي كاساندرا.
Normalized tables will need to go through the process of
ستحتاج الجداول التي تمت تسويتها إلى المرور بعملية
denormalization to be able to fit into the Apache Cassandra data model.
عدم التطابق لتكون قادرًا على التوافق مع نموذج بيانات Apache Cassandra.
What queries will be performed on that data?
ما هي الاستعلامات التي سيتم إجراؤها على تلك البيانات؟
This is what you'll need to know in advance.
هذا ما ستحتاج إلى معرفته مسبقًا.
This must be the number one priority
يجب أن تكون هذه الأولوية رقم واحد
when doing data modelling in NoSQL or Apache Cassandra.
عند القيام بنمذجة البيانات في NoSQL أو Apache Cassandra.
Again, if you're migrating some of your workloads from relational to a NoSQL database,
مرة أخرى ، إذا كنت تقوم بترحيل بعض أعباء عملك من الارتباط إلى قاعدة بيانات NoSQL ،
it cannot be transformed as is.
لا يمكن تحويلها كما هي.
You're going to have to do some new data modelling task on
سيتعين عليك القيام ببعض مهام نمذجة البيانات الجديدة
it to be able to get it transform into the correct data model.
لتكون قادرة على تحويلها إلى نموذج البيانات الصحيح.
If you walk away knowing that, you're in good shape.
إذا ابتعدت وأنت تعلم ذلك ، فأنت في حالة جيدة.
So let's talk a little bit more about data modelling in Apache Cassandra.
لذلك دعونا نتحدث قليلاً عن نمذجة البيانات في Apache Cassandra.
So denormalization is not just okay, it's a must.
لذا فإن عدم التطابق ليس جيدًا فحسب ، بل إنه أمر لا بد منه.
Normalization into third normal form will not work in Apache Cassandra.
التطبيع في النموذج العادي الثالث لن يعمل في Apache Cassandra.
There are no joins in Apache Cassandra.
لا توجد صلات في أباتشي كاساندرا.
Without joins, I can only query on one table at a time.
بدون الصلات ، يمكنني الاستعلام فقط على جدول واحد في كل مرة.
Denormalization must be done for fast reads.
يجب أن يتم إلغاء التطابق للقراءات السريعة.
Apache Cassandra has been optimized for fast writes.
تم تحسين Apache Cassandra للكتابة السريعة.
Again, if we were talking more about the architecture of Apache Cassandra,
مرة أخرى ، إذا كنا نتحدث أكثر عن هندسة أباتشي كاساندرا ،
you'd be able to see that the right path is actually very beautiful in its simplicity.
ستكون قادرًا على رؤية أن الطريق الصحيح جميل جدًا في الواقع في بساطته.
But if you want fast write, pardon me.
ولكن إذا كنت تريد الكتابة بسرعة ، فاعذرني.
If you want fast reads,
إذا كنت تريد قراءات سريعة ،
you must set yourself up for success with a good data model.
يجب أن تهيئ نفسك للنجاح باستخدام نموذج بيانات جيد.
Nothing is magic and nothing comes for free.
لا شيء سحر ولا شيء يأتي بالمجان.
So because of that you're going to have to set yourself up with a good data model.
لهذا السبب ، سيتعين عليك إعداد نموذج بيانات جيد.
Again, think queries first.
مرة أخرى ، فكر في الاستفسارات أولاً.
If you walk away knowing that, you're in good shape.
إذا ابتعدت وأنت تعلم ذلك ، فأنت في حالة جيدة.
In relational data modeling,
في نمذجة البيانات العلائقية ،
we were concerned about slow writes with denormalized tables.
كنا قلقين بشأن عمليات الكتابة البطيئة مع الجداول غير الطبيعية.
Since you'll have duplicates of your data and need to write
نظرًا لأنه سيكون لديك نسخ مكررة من بياناتك وتحتاج إلى الكتابة
update and insert to more than one table for the same piece of data.
التحديث والإدراج في أكثر من جدول لنفس قطعة البيانات.
But because Apache Cassandra has been optimized for that,
ولكن نظرًا لأنه تم تحسين Apache Cassandra من أجل ذلك ،
there should be no concern.
يجب ألا يكون هناك قلق.
Again, no joins.
مرة أخرى ، لا ينضم.
One table per query is a great strategy.
يعد الجدول الواحد لكل استعلام إستراتيجية رائعة.
This will lead to data replication.
سيؤدي هذا إلى تكرار البيانات.
You're going to have redundant data.
سيكون لديك بيانات زائدة عن الحاجة.
You're going to have extra copies of your data.
سيكون لديك نسخ إضافية من بياناتك.
Basically, the exact opposite of what we're worried about in lesson two.
في الأساس ، هو عكس ما يقلقنا في الدرس الثاني.
But the performance benefits and high availability of
لكن فوائد الأداء والتوافر العالي لـ
the system far outweigh any additional storage costs.
يفوق النظام بكثير أي تكاليف تخزين إضافية.
Remember, storage is an expensive.
تذكر أن التخزين مكلف.
Losing customers to outages or low latency is not.
إن خسارة العملاء بسبب الانقطاعات أو التأخير المنخفض ليست كذلك.
Let's take a look at this graphic here.
دعنا نلقي نظرة على هذا الرسم هنا.
So here, we're talking about again,
هنا ، نتحدث مرة أخرى ،
a good comparison between Relational Databases and
مقارنة جيدة بين قواعد البيانات العلائقية و
NoSQL Databases or thinking about data
قواعد بيانات NoSQL أو التفكير في البيانات
modelling and the fact that we no longer have joins.
النمذجة وحقيقة أنه لم يعد لدينا صلات.
So in this case in a relational database,
في هذه الحالة في قاعدة البيانات العلائقية ،
we can have our query represented here.
يمكننا تمثيل استعلامنا هنا.
We can have one query that's accessing two tables,
يمكن أن يكون لدينا استعلام واحد يصل إلى جدولين ،
three tables, as many tables as we want because we can join them together.
ثلاثة جداول ، أي عدد من الجداول كما نريد لأنه يمكننا ربطها معًا.
Now, in NoSQL databases, again,
الآن ، في قواعد بيانات NoSQL ، مرة أخرى ،
one query per one table.
استعلام واحد لكل جدول واحد.
One query per one table.
استعلام واحد لكل جدول واحد.
You cannot join the data together.
لا يمكنك ضم البيانات معا.
You can only access one table at a time.
يمكنك فقط الوصول إلى جدول واحد في كل مرة.
Just to reiterate the idea of no joins and using one query on one table.
فقط لتكرار فكرة عدم الصلات واستخدام استعلام واحد في جدول واحد.
This diagram compares the approach for
يقارن هذا الرسم البياني نهج
relational versus NoSQL databases like Apache Cassandra.
علائقية مقابل قواعد بيانات NoSQL مثل Apache Cassandra.
In relational databases, one query can access and join data from multiple tables.
في قواعد البيانات العلائقية ، يمكن لاستعلام واحد الوصول إلى البيانات وضمها من جداول متعددة.
In Apache Cassandra, the queries can pull data from a single table.
في Apache Cassandra ، يمكن للاستعلامات سحب البيانات من جدول واحد.
This is important to model with your data in mind.
هذا مهم للنمذجة مع وضع بياناتك في الاعتبار.
So again, think two queries, two different tables.
لذا مرة أخرى ، فكر في استعلامين ، جدولين مختلفين.
So let's say I want to do two queries.
لنفترض أنني أريد إجراء استعلامين.
One is all albums in a given year and all albums by given artist.
واحد هو جميع الألبومات في عام معين وجميع الألبومات لفنان معين.
So, here's just a quick example of what that would look like.
إذن ، هذا مجرد مثال سريع لما سيبدو عليه ذلك.
So in this case, I want to get all albums by particular year.
لذلك في هذه الحالة ، أريد الحصول على جميع الألبومات حسب سنة معينة.
So I'm going to do a select star from music library,
لذلك سأقوم بتحديد نجمة من مكتبة الموسيقى ،
where year equals and then I can fill in whatever year that I'm looking for.
حيث العام يساوي ، وبعد ذلك يمكنني ملء أي سنة أبحث عنها.
Over here, I want to do a select star from album library where again,
هنا ، أريد تحديد نجمة من مكتبة الألبومات حيث
a different table where the artist name equals the Beatles.
جدول مختلف حيث يساوي اسم الفنان فرقة البيتلز.
So in this case,
لذلك في هذه الحالة ،
we have partitioned our data by year and in this case we've
لقد قسمنا بياناتنا حسب السنة وفي هذه الحالة قمنا بتقسيم بياناتنا
partitioned our data artist's name. No don't be afraid.
قسمت اسم فنان البيانات لدينا. لا لا تخافوا.
You're seeing a lot of duplicate data between these two tables and that is okay.
أنت ترى الكثير من البيانات المكررة بين هذين الجدولين ولا بأس بذلك.
If you're getting a little lost on when I said partitioning of the data,
إذا كنت تشعر بالضياع قليلاً عندما قلت تقسيم البيانات ،
we're going to talk about that a lot more here very soon.
سنتحدث عن ذلك كثيرًا هنا قريبًا جدًا.
So again, the data in these tables is going to be duplicated.
لذا مرة أخرى ، سيتم تكرار البيانات الموجودة في هذه الجداول.
But that's okay in the nature of having denormalized tables.
لكن هذا أمر جيد في طبيعة وجود جداول غير طبيعية.
What is important is that we have two queries that we're able to
المهم هو أن لدينا استعلامين يمكننا الإجابة عليهما
execute against our data in a high-performance, no downtime system.
التنفيذ وفقًا لبياناتنا بأداء عالٍ وبدون نظام تعطل.
So just a quick word on CQL.
إذن مجرد كلمة سريعة عن CQL.
Cassandra Query Language is the way that we interact with the database.
لغة Cassandra Query هي الطريقة التي نتفاعل بها مع قاعدة البيانات.
It's very similar to SQL, except again,
إنه مشابه جدًا لـ SQL ، باستثناء مرة أخرى ،
no JOIN no GROUP BY and there's not any subqueries,
لا JOIN no GROUP BY وليس هناك أي استعلامات فرعية ،
and they're not in CQL and they're not supported by CQL.
وهم ليسوا في CQL ولا تدعمهم CQL.
In prior years, authentic Cassandra tables were assessed using a protocol called Thrift.
في السنوات السابقة ، تم تقييم جداول كاساندرا الأصلية باستخدام بروتوكول يسمى التوفير.
But that was very difficult to use and
ولكن كان من الصعب جدًا استخدام و
hard for users coming from the relational CQL world.
صعب للمستخدمين القادمين من عالم CQL العلائقي.
There are many language drivers,
هناك العديد من برامج تشغيل اللغة ،
majority supported by datastacks to integrate into an application.
الأغلبية مدعومة من datastacks للاندماج في التطبيق.
You've seen in lesson one in our demos and the exercises,
لقد رأيت في الدرس الأول في العروض التوضيحية والتدريبات ،
we were we're utilizing the Python driver.
كنا نستخدم برنامج بايثون.
Other popular drivers are Java,
برامج التشغيل الشائعة الأخرى هي Java ،
C sharp, NodeJS, etc.
C حاد ، NodeJS ، إلخ.
There's many many out there,
هناك الكثير في الخارج ،
and again, they're all open source.
ومرة أخرى ، جميعها مفتوحة المصدر.
So if you have an idea for a new one, submit the code.
لذا إذا كانت لديك فكرة عن فكرة جديدة ، أرسل الكود.
Go for it, go develop it.
اذهب من أجلها ، اذهب وقم بتطويرها.
We'll continue to use the Python driver in the next set of demos and exercises.
سنستمر في استخدام برنامج تشغيل Python في المجموعة التالية من العروض التوضيحية والتدريبات.
So, the primary key is how each row can be uniquely
لذا ، فإن المفتاح الأساسي هو كيف يمكن أن يكون كل صف فريدًا
identified and how the data is distributed across the nodes or servers in our system.
تم تحديدها وكيفية توزيع البيانات عبر العقد أو الخوادم في نظامنا.
The first element of the primary key is
العنصر الأول للمفتاح الأساسي هو
the partition key which will determined the distribution.
مفتاح القسم الذي سيحدد التوزيع.
The primary key is made up of
يتكون المفتاح الأساسي من
either just the partition key or with the addition of clustering columns.
إما مفتاح القسم فقط أو مع إضافة أعمدة التجميع.
Again, the primary key is made up of
مرة أخرى ، يتكون المفتاح الأساسي من
either just the partition key or with the addition of clustering columns.
إما مفتاح القسم فقط أو مع إضافة أعمدة التجميع.
The partition key will determine the distribution of data across the system.
سيحدد مفتاح القسم توزيع البيانات عبر النظام.
The partition keys row value will be hashed,
سيتم تجزئة قيمة صف مفاتيح القسم ،
turned into a number and stored on
تحولت إلى رقم وتم تخزينها على
the node in the system that holds that range of values.
العقدة في النظام التي تحتفظ بهذا النطاق من القيم.
I'm just letting you know that extra piece of information there.
أنا فقط أخبرك بهذا الجزء الإضافي من المعلومات هناك.
Again, this goes more into the design and architecture of distributed databases.
مرة أخرى ، يذهب هذا أكثر إلى تصميم وهندسة قواعد البيانات الموزعة.
So, if you're interested in this topic there's
لذا ، إذا كنت مهتمًا بهذا الموضوع ، فهناك
much more information out there that you can access to learn about that.
المزيد من المعلومات التي يمكنك الوصول إليها للتعرف على ذلك.
Alright. So, here's an example of a primary key
على ما يرام. إذن ، هذا مثال على مفتاح أساسي
using a simple primary key which is also our partition key.
باستخدام مفتاح أساسي بسيط وهو أيضًا مفتاح القسم الخاص بنا.
So, I'm going to create table music library.
لذلك ، سأقوم بإنشاء مكتبة موسيقى الطاولة.
Again, your int is going to be int,
مرة أخرى ، ستكون int ،
artist name is text and album name text and then our primary key will be then by year.
اسم الفنان هو نص ونص اسم الألبوم وبعد ذلك سيكون مفتاحنا الأساسي حسب السنة.
So again, that means our data will be distributed across our system by the year.
مرة أخرى ، هذا يعني أن بياناتنا سيتم توزيعها عبر نظامنا بحلول العام.
So, our primary key is also our partition key.
لذلك ، مفتاحنا الأساسي هو أيضًا مفتاح القسم الخاص بنا.
So, some key points about primary keys,
إذن ، بعض النقاط الأساسية حول المفاتيح الأساسية ،
they must be unique.
يجب أن تكون فريدة من نوعها.
A primary key must be unique to each row.
يجب أن يكون المفتاح الأساسي فريدًا لكل صف.
There are no duplicates in Apache Cassandra.
لا توجد تكرارات في Apache Cassandra.
Think about your primary key,
فكر في مفتاحك الأساسي ،
is it going to end up resolving to a single?
هل سينتهي الأمر إلى حل واحد؟
Row. If you make your primary key first name,
صف. إذا قمت بإجراء الاسم الأول للمفتاح الأساسي ،
only one Amanda will be allowed in your database,
لن يُسمح إلا بأماندا واحدة في قاعدة البيانات الخاصة بك ،
but this is a very common name and there will be more than one.
لكن هذا اسم شائع جدًا وسيكون هناك أكثر من اسم.
Data will be overwritten if a new value comes in with the same primary key.
ستتم الكتابة فوق البيانات إذا كانت هناك قيمة جديدة تأتي مع نفس المفتاح الأساسي.
An error will not be thrown and the original data will be overwritten.
لن يتم طرح أي خطأ وسيتم استبدال البيانات الأصلية.
Hashing of this value results in placement on particular nodes in the system.
ينتج عن تجزئة هذه القيمة التنسيب على عقد معينة في النظام.
The value will be hashed to a numeric value
ستتم تجزئة القيمة إلى قيمة رقمية
and the value will determine whether data will live on the system.
وستحدد القيمة ما إذا كانت البيانات ستعيش على النظام.
Either node one, node two or node 7,000.
إما العقدة الأولى أو العقدة الثانية أو العقدة 7000.
Data distributed by this partition key.
يتم توزيع البيانات بواسطة مفتاح القسم هذا.
The data will be distributed across the system by this key.
سيتم توزيع البيانات عبر النظام بواسطة هذا المفتاح.
You want to pick a key that will evenly distribute the data as best you can.
تريد اختيار مفتاح يوزع البيانات بالتساوي بأفضل ما يمكنك.
For example, if you've distributed a customer table by state,
على سبيل المثال ، إذا قمت بتوزيع جدول عميل حسب الولاية ،
you're likely to see an uneven distribution
من المحتمل أن ترى توزيعًا غير متساوٍ
because more people live in California than Vermont.
لأن عدد سكان كاليفورنيا يفوق عدد سكان ولاية فيرمونت.
Simple or composite.
بسيط أو مركب.
The simple primary key is just one column that is also the partition key.
المفتاح الأساسي البسيط هو عمود واحد فقط وهو أيضًا مفتاح القسم.
A composite primary key is made up of more than one column and will assist in creating
يتكون المفتاح الأساسي المركب من أكثر من عمود وسيساعد في الإنشاء
a unique value and will help you in getting your retrieval queries.
قيمة فريدة وستساعدك في الحصول على استفسارات الاسترجاع الخاصة بك.
They have one or more clustering columns.
لديهم عمود تجميع واحد أو أكثر.
We'll talk more about clustering columns in the next section.
سنتحدث أكثر عن تجميع الأعمدة في القسم التالي.
Again, here's our composite key.
مرة أخرى ، هذا هو مفتاحنا المركب.
So, now we're seeing that same type of query that we had before on
لذلك ، نرى الآن نفس نوع الاستعلام الذي كان لدينا من قبل
music library of the create table and in this case,
مكتبة الموسيقى لجدول الإنشاء وفي هذه الحالة ،
we have primary key and we have a composite key.
لدينا مفتاح أساسي ولدينا مفتاح مركب.
We're going to distribute by year with a combination of artist name.
سنقوم بالتوزيع حسب السنة بمزيج من اسم الفنان.
So, both of these are the partition key,
إذن ، كلاهما يمثلان مفتاح التقسيم ،
these values will be hashed together.
سيتم تجزئة هذه القيم معًا.
You'll get one value back and then that data will be stored on a particular node.
ستحصل على قيمة واحدة مرة أخرى وبعد ذلك سيتم تخزين تلك البيانات على عقدة معينة.
All of this together is the primary key.
كل هذا معًا هو المفتاح الأساسي.
ll right. So let's go on to our next demo which is going to
حسنا. لذلك دعنا ننتقل إلى العرض التوضيحي التالي الذي سيحدث
focus on utilizing and using our primary key.
التركيز على استخدام واستخدام مفتاحنا الأساسي.
I'm going to my Jupyter Notebook,
أنا ذاهب إلى دفتر Jupyter الخاص بي ،
and I'm going to open lesson three,
وسأفتح الدرس الثالث ،
demo two, all about the primary key.
العرض الثاني ، كل شيء عن المفتاح الأساسي.
So, let's focus on that.
لذا ، دعونا نركز على ذلك.
By the way, this eye is the Cassandra logo if anybody was wondering.
بالمناسبة ، هذه العين هي شعار كاساندرا إذا كان أي شخص يتساءل.
In this demo, we're going to walk through the basics of creating a table,
في هذا العرض التوضيحي ، سنستعرض أساسيات إنشاء الجدول ،
with a good primary key in Apache Cassandra,
بمفتاح أساسي جيد في Apache Cassandra ،
inserting rows of data,
إدخال صفوف من البيانات ،
and doing a simple SQL query to validate the information.
وإجراء استعلام SQL بسيط للتحقق من صحة المعلومات.
We're going to import our library,
سنقوم باستيراد مكتبتنا ،
we're going to connect to the database,
سنقوم بالاتصال بقاعدة البيانات ،
and we're going to create our key space if it doesn't already exist,
وسننشئ مساحتنا الرئيسية إذا لم تكن موجودة بالفعل ،
and we'll connect to that key space.
وسنتصل بهذه المساحة الرئيسية.
Let's Imagine we'd like to start creating a new music library of albums.
دعنا نتخيل أننا نرغب في البدء في إنشاء مكتبة موسيقية جديدة من الألبومات.
We're going to work through one of the queries from exercise one.
سنعمل على حل أحد الاستفسارات من التمرين الأول.
We want to ask one question of our data: Give me
نريد أن نطرح سؤالاً واحداً من بياناتنا: أعطني
every album in my music library that was released in a given year.
كل ألبوم في مكتبتي الموسيقية تم إصداره في عام معين.
Select star from music_library,
حدد نجمة من music_library ،
where year equals 1970.
حيث العام يساوي 1970.
Here's the collection of our data.
ها هي مجموعة بياناتنا.
Here's the year, we have information about the city,
ها هي السنة ولدينا معلومات عن المدينة ،
we have artist's name and album name. So let's look at our data.
لدينا اسم الفنان واسم الألبوم. لذلك دعونا نلقي نظرة على بياناتنا.
How should we model this data?
كيف يمكننا نمذجة هذه البيانات؟
Let's think about it. What should be our primary key?
دعونا نفكر في ذلك. ماذا يجب أن يكون مفتاحنا الأساسي؟
What should be our partition key?
ماذا يجب أن يكون مفتاح القسم لدينا؟
Since our data is looking for the year, let's start with that.
نظرًا لأن بياناتنا تبحث عن العام ، فلنبدأ بذلك.
Is partitioning our data by year a good idea?
هل تقسيم بياناتنا حسب السنة فكرة جيدة؟
In this case, our data is very small.
في هذه الحالة ، بياناتنا صغيرة جدًا.
But if we had a large data set of albums partitioned by year,
ولكن إذا كانت لدينا مجموعة بيانات كبيرة من الألبومات مقسمة حسب السنة ،
it may be a fine choice.
قد يكون اختيارًا جيدًا.
You would need to validate from your data set,
ستحتاج إلى التحقق من مجموعة البيانات الخاصة بك ،
look at your own data and then model it to that.
انظر إلى بياناتك الخاصة ثم نمذجتها وفقًا لذلك.
But, essentially, we want to spread the data equally across our nodes.
لكن ، في الأساس ، نريد نشر البيانات بالتساوي عبر عقدنا.
So, in this case, we're going to create a table called music_library with a column year,
لذلك ، في هذه الحالة ، سننشئ جدولًا يسمى music_library بسنة عمود ،
artist's name, album name, and city,
اسم الفنان واسم الألبوم والمدينة ،
and our primary key is going to be on year.
وسيكون مفتاحنا الأساسي في العام.
So let's create our table.
لذلك دعونا ننشئ طاولتنا.
Let's insert our data into the table.
دعنا ندخل بياناتنا في الجدول.
So we're going to insert all that data we saw up above in this chart.
لذلك سنقوم بإدخال كل تلك البيانات التي رأيناها أعلاه في هذا المخطط.
So, let's insert into our table,
لذا ، دعنا ندرج في طاولتنا ،
and let's validate our data model, Did it work?
ودعنا نتحقق من صحة نموذج البيانات الخاص بنا ، هل نجح؟
In this case, we can use the year 1970 or we can use any year.
في هذه الحالة ، يمكننا استخدام عام 1970 أو يمكننا استخدام أي عام.
So I'm showcasing this here.
لذلك أنا أعرض هذا هنا.
So we're going to look for albums that were released in 1965.
لذلك سنبحث عن الألبومات التي تم إصدارها في عام 1965.
We should expect to see two rows.
يجب أن نتوقع رؤية صفين.
So let's go back here to our chart.
لنعد هنا إلى الرسم البياني.
As you can see, there is The Beatles and Rubber Soul, 1965.
كما ترون ، هناك فرقة البيتلز وروبر سول عام 1965.
We also have The Who,
لدينا أيضًا The Who ،
My Generation also 1965.
جيلي أيضًا عام 1965.
So I should expect to see those two back when I run this query.
لذلك يجب أن أتوقع رؤية هذين الأمرين عند تشغيل هذا الاستعلام.
That didn't work out. Why is that?
هذا لم ينجح. لماذا هذا؟
Because we did not create a unique primary key. That's why.
لأننا لم ننشئ مفتاحًا أساسيًا فريدًا. لهذا.
So, I had written in that 1965 for The Beatles,
لذلك ، كتبت في عام 1965 لصالح فريق البيتلز ،
and then it got overwritten by The Who,
ثم تمت الكتابة فوقه بواسطة The Who ،
My Generation. So let's try again.
جيلي. لذلك دعونا نحاول مرة أخرى.
Let's focus on making the primary key unique.
دعونا نركز على جعل المفتاح الأساسي فريدًا.
Look at our data set.
انظر إلى مجموعة البيانات لدينا.
Do we have anything that is unique for each row?
هل لدينا أي شيء فريد لكل صف؟
We have a couple of options.
لدينا خياران.
In this case, we have city and album name,
في هذه الحالة ، لدينا اسم المدينة والألبوم ،
but that will not give us the query we need,
لكن هذا لن يعطينا الاستعلام الذي نحتاجه ،
which we are looking for the album in a particular year.
الذي نبحث عنه الألبوم في سنة معينة.
Let's make a composite key of the year and the album name.
لنصنع مفتاحًا مركبًا للسنة واسم الألبوم.
This is assuming that the album name is unique to that year.
هذا على افتراض أن اسم الألبوم فريد من نوعه لتلك السنة.
Pardon me. That is assuming that the album name is unique to the year it was released.
اعذرني. هذا على افتراض أن اسم الألبوم فريد من نوعه في العام الذي تم إصداره فيه.
This is not a bad bet.
هذا ليس رهانًا سيئًا.
But, remember, this is just a demo.
لكن تذكر أن هذا مجرد عرض توضيحي.
You will need to fully understand your own data set.
سوف تحتاج إلى فهم كامل لمجموعة البيانات الخاصة بك.
No betting on your own data.
لا تراهن على بياناتك الخاصة.
So, we're going to create the table,
لذلك ، سننشئ الجدول ،
and again we're going to use a composite key here with year and album name.
ومرة أخرى سنستخدم مفتاحًا مركبًا هنا مع اسم السنة والألبوم.
We're going to create that query,
سنقوم بإنشاء هذا الاستعلام ،
and again we're going to do our insert.
ومرة أخرى سنقوم بالملحق الخاص بنا.
So, let's validate our data model. Did it work?
لذلك ، دعنا نتحقق من صحة نموذج البيانات الخاص بنا. هل نجحت؟
If we look for albums from 1965,
إذا بحثنا عن ألبومات من عام 1965 ،
now we should see two rows.
الآن يجب أن نرى صفين.
Awesome, success. It worked.
رائع ، نجاح. انها عملت.
We created a unique primary key that evenly distributed our data.
أنشأنا مفتاحًا أساسيًا فريدًا وزع بياناتنا بالتساوي.
For the sake of the demo, I will drop the tables,
من أجل العرض التوضيحي ، سأقوم بإسقاط الطاولات ،
and we're going to close our connection.
وسنقوم بإغلاق اتصالنا.
Now let's move on to clustering columns.
الآن دعنا ننتقل إلى تجميع الأعمدة.
Clustering columns- The PRIMARY KEY is made up of
أعمدة التجميع - يتكون المفتاح الأساسي من
either just the PARTITION KEY or with the addition of CLUSTERING COLUMNS.
إما مجرد مفتاح التقسيم أو مع إضافة الأعمدة العنقودية.
The CLUSTERING COLUMNS will determine the sort order within a Partition.
ستحدد أعمدة التجميع ترتيب الفرز داخل القسم.
The clustering columns will sort the data in sorted descending order.
ستعمل أعمدة التجميع على فرز البيانات بترتيب تنازلي.
More than one clustering column can be added or like we talked about before, or none.
يمكن إضافة أكثر من عمود تجميع واحد أو كما تحدثنا من قبل ، أو لا شيء.
So, in this case,
لذلك ، في هذه الحالة ،
we have a Composite key with it we're partitioning by year,
لدينا مفتاح مركب معه نقسمه حسب السنة ،
and then from there we have a clustering column on artist's name, and album name.
ومن ثم لدينا عمود تجميعي عن اسم الفنان واسم الألبوم.
So, you can see here in this example if I did a select star from that music library,
لذا ، يمكنك أن ترى هنا في هذا المثال إذا قمت بتحديد نجمة من مكتبة الموسيقى هذه ،
you can see that I have my year,
يمكنك أن ترى أن لدي سنتي ،
and then my artist's name which is then in alphabetical order in descending order;
ثم اسم فناني بترتيب أبجدي تنازلي ؛
E comes before T,
يأتي E قبل T ،
and B comes before M. Then after that,
وتأتي "ب" قبل "م" ثم بعد ذلك ،
it's going to sort by album name.
سيتم الترتيب حسب اسم الألبوم.
So, here you can see again so,
لذا ، هنا يمكنك أن ترى مرة أخرى ،
Elvis so Blue Hawaii,
الفيس سو بلو هاواي
and then we're going to sort the Beatles.
وبعد ذلك سنقوم بفرز فرقة البيتلز.
Here we're going to have Rubber Soul,
هنا سيكون لدينا روح مطاطية ،
and then here I just wanted to make sure it was something that came after Rubber Soul,
وبعد ذلك أردت فقط التأكد من أنه شيء جاء بعد "الروح المطاطية" ،
so I made it not really an album it's called, 'Showing the order'.
لذلك لم أجعله حقًا ألبومًا يسمى ، "عرض الطلب".
So, here it's going to be in descending order as you can see.
لذلك ، سيكون هنا ترتيبًا تنازليًا كما ترون.
Then here we'll have the item for the Monkees.
ثم هنا سيكون لدينا عنصر Monkees.
From there, the clustering column will sort in sorted order,
من هناك ، سيتم فرز عمود التجميع بالترتيب الفرز ،
and how they were added to the primary key.
وكيف تمت إضافتهم إلى المفتاح الأساسي.
So, for example, in this example that I just showed,
لذلك ، على سبيل المثال ، في هذا المثال الذي عرضته للتو ،
they will be distributed by the key,
سيتم توزيعها بواسطة المفتاح ،
then sorted in descending order by first the artist's name, and then the album name.
ثم تم الترتيب تنازليًا حسب اسم الفنان أولاً ، ثم اسم الألبوم.
So, the primary key is made up of a partition key which in this case is year,
لذلك ، يتكون المفتاح الأساسي من مفتاح قسم وهو في هذه الحالة عام ،
and a clustering column which is the artist's name.
وعمود تجميع وهو اسم الفنان.
Remember this is just an example.
تذكر أن هذا مجرد مثال.
It might not be unique enough of a value.
قد لا يكون فريدًا بما يكفي لقيمة.
Let's say that the artist created two albums in one year.
لنفترض أن الفنان أنشأ ألبومين في عام واحد.
Then this data model would not hold up.
ثم لن يصمد نموذج البيانات هذا.
But just for the sake of this demo,
ولكن فقط من أجل هذا العرض التوضيحي ،
we're going to assume that it's unique.
سنفترض أنه فريد من نوعه.
So, here we're going to clustering or excuse me,
لذلك ، سنقوم هنا بتجميع أو إعفاء ،
our partition key here which is year,
مفتاح التقسيم هنا وهو العام ،
and our clustering column artist's name.
واسم الفنان في عمود التجميع لدينا.
All right. So, let's look at a demo,
حسنا. لذلك ، دعونا نلقي نظرة على العرض التوضيحي ،
let's focus on clustering columns.
دعونا نركز على تجميع الأعمدة.
In this demo, we're going to walk through the basics of
في هذا العرض التوضيحي ، سنستعرض أساسيات
creating a table with a good primary key,
إنشاء جدول بمفتاح أساسي جيد ،
and clustering columns in Apache Cassandra,
وتجميع الأعمدة في أباتشي كاساندرا ،
inserting rows of data,
إدخال صفوف من البيانات ،
and doing a simple SQL query to validate the information.
وإجراء استعلام SQL بسيط للتحقق من صحة المعلومات.
For your package, connect your database,
لحزمتك ، قم بتوصيل قاعدة البيانات الخاصة بك ،
connect your keyspace. All right.
قم بتوصيل keyspace الخاص بك. حسنا.
Let's imagine we'd like to start creating a new music library of albums.
لنتخيل أننا نرغب في البدء في إنشاء مكتبة موسيقية جديدة من الألبومات.
We've created a lot of music library albums tables in this lesson, so,
لقد أنشأنا الكثير من جداول ألبومات مكتبات الموسيقى في هذا الدرس ،
imagine there are other things that you can do
تخيل أن هناك أشياء أخرى يمكنك القيام بها
data modeling on other than music libraries,
نمذجة البيانات على غير مكتبات الموسيقى ،
but this is just what we're going to use to walk as through.
ولكن هذا ما سنستخدمه للمشي من خلاله.
We want to ask one question of our data,
نريد أن نطرح سؤالاً واحداً من بياناتنا ،
give me every album in my music library that was released by
أعطني كل ألبوم في مكتبتي الموسيقية تم إصداره بواسطة
an artist with album name in descending order and city in descending order.
فنان باسم ألبوم بترتيب تنازلي والمدينة بترتيب تنازلي.
So, my query might look something like this,
لذلك ، قد يبدو طلب البحث الخاص بي شيئًا كهذا ،
select star from music library or artist name equals the Beatles.
حدد نجمة من مكتبة الموسيقى أو اسم فنان يساوي فرقة البيتلز.
So, then here's my collection of data that I have.
إذن ، ها هي مجموعتي من البيانات التي لدي.
So, how should we model this data?
إذن ، كيف يمكننا نمذجة هذه البيانات؟
What should be our primary key and our partition key?
ما الذي يجب أن يكون مفتاحنا الأساسي ومفتاح القسم الخاص بنا؟
Since our data is looking for the artist name, let's start with that.
نظرًا لأن بياناتنا تبحث عن اسم الفنان ، فلنبدأ بذلك.
From there, we'll need to add other elements to make sure that the key is unique.
من هناك ، سنحتاج إلى إضافة عناصر أخرى للتأكد من أن المفتاح فريد.
Again, because we need to start with artist name,
مرة أخرى ، لأننا نحتاج أن نبدأ باسم الفنان ،
we have duplicates, for example, for the Beatles,
لدينا نسخ مكررة ، على سبيل المثال ، لفرقة البيتلز ،
we have three rows that have the Beatles as their artist's name.
لدينا ثلاثة صفوف عليها اسم فريق البيتلز.
So that's not going to be unique enough to be our soul partition key.
لذلك لن يكون هذا فريدًا بما يكفي ليكون مفتاح تقسيم روحنا.
So we're going to need to add other elements to make sure that the key is unique.
لذلك سنحتاج إلى إضافة عناصر أخرى للتأكد من أن المفتاح فريد.
We also need to add the city,
نحتاج أيضًا إلى إضافة المدينة ،
and the album name as clustering columns to sort the data.
واسم الألبوم كأعمدة تجميع لفرز البيانات.
That shouldn't be enough to make our row key unique.
لا ينبغي أن يكون ذلك كافيًا لجعل مفتاح الصف فريدًا.
So, we're going to have music library,
لذلك ، سيكون لدينا مكتبة موسيقى ،
column year, artist name, album name, and city.
سنة العمود واسم الفنان واسم الألبوم والمدينة.
So again, we're going to start with our partition key,
لذا مرة أخرى ، سنبدأ بمفتاح القسم الخاص بنا ،
our partition key always goes first,
يذهب مفتاح التقسيم دائمًا أولاً ،
artist name, from there we're going to have album name, and city.
اسم الفنان ، من هناك سيكون لدينا اسم الألبوم والمدينة.
Let's create the table if it does not exist.
لنقم بإنشاء الجدول إذا لم يكن موجودًا.
Again, album name and city are our clustering columns.
مرة أخرى ، اسم الألبوم والمدينة هما أعمدة التجميع لدينا.
Great, let's insert our data into the table.
رائع ، دعنا ندخل بياناتنا في الجدول.
Again this looks like all the other inserts that we've done before.
مرة أخرى ، يبدو هذا مثل جميع الإدخالات الأخرى التي قمنا بها من قبل.
Let's validate our data model.
دعنا نتحقق من صحة نموذج البيانات الخاص بنا.
Did it work?
هل نجحت؟
If we look for albums from the Beatles,
إذا بحثنا عن ألبومات من فرقة البيتلز ،
we should expect to see three rows.
يجب أن نتوقع رؤية ثلاثة صفوف.
Again here's our query,
مرة أخرى هنا استعلامنا ،
select star from music library were artist's name equals the Beatles,
اختر نجمة من مكتبة الموسيقى واسم الفنان يساوي فرقة البيتلز ،
and we're going to run that query and print the result.
وسنقوم بتشغيل هذا الاستعلام وطباعة النتيجة.
Awesome. The Beatles, Beatles For Sale London 1964,
رائع. البيتلز ، البيتلز للبيع لندن 1964 ،
The Beatles Let it Be Liverpool,
فريق البيتلز وليكن ليفربول ،
The Beatles Rubber Soul and Oxford.
فرقة البيتلز المطاطية الروح وأكسفورد.
So as you can see,
كما ترون ،
we have our partition key,
لدينا مفتاح القسم الخاص بنا ،
and then our clustering columns are in order.
ثم أعمدة التجميع لدينا بالترتيب.
Beatles, let, and rubber that's in descending order.
البيتلز ، واللي ، والمطاط بترتيب تنازلي.
Success, it worked.
النجاح ، لقد نجح.
We created a unique primary key that evenly distributed our data,
أنشأنا مفتاحًا أساسيًا فريدًا وزع بياناتنا بالتساوي ،
with clustering columns that sorted our data,
مع تجميع الأعمدة التي صنفت بياناتنا ،
and for the sake of the demo I will drop the table,
ومن أجل العرض التوضيحي سوف أترك الطاولة ،
and finally am going to close my session.
وأخيرًا سأغلق جلستي.
So, now we're going to be talking about the WHERE clause.
لذا ، سنتحدث الآن عن بند WHERE.
We've been utilizing the WHERE clause
لقد تم استخدام بند WHERE
extensively through lesson one through lesson three.
على نطاق واسع من خلال الدرس الأول من خلال الدرس الثالث.
But I really want to dive deep on how we're actually using it?
لكنني أريد حقًا التعمق في كيفية استخدامنا له بالفعل؟
The best ways to use it et cetera.
أفضل الطرق لاستخدامه وما إلى ذلك.
Data modeling and Apache Cassandra is query focused.
تركز نمذجة البيانات و Apache Cassandra على الاستعلام.
The focus needs to be on the WHERE clause.
يجب أن يكون التركيز على جملة WHERE.
The partition key must be included in your query and
يجب تضمين مفتاح القسم في الاستعلام الخاص بك و
any clustering columns that can be used in the order they appear in your primary key.
أي أعمدة تجميع يمكن استخدامها بالترتيب الذي تظهر به في مفتاحك الأساسي.
Failure to include a WHERE clause will result in an error.
سيؤدي عدم تضمين عبارة WHERE إلى حدوث خطأ.
Let's walk through an example with our music library table.
دعنا نتعرف على مثال مع طاولة مكتبة الموسيقى الخاصة بنا.
Because we have quite a few queries on this screen here.
لأن لدينا عددًا قليلاً من الاستفسارات على هذه الشاشة هنا.
Let's walk through them one by one.
دعونا نسير من خلالهم واحدًا تلو الآخر.
So, the first query here,
إذن ، أول طلب بحث هنا ،
select star for music library where year equals 1965.
اختر نجمة لمكتبة الموسيقى حيث العام يساوي 1965.
Will get you back everything in your partition.
سوف تعيد لك كل شيء في قسمك.
This is all the data you have stored on one node.
هذه هي جميع البيانات التي قمت بتخزينها على عقدة واحدة.
Be careful with this type of query.
كن حذرا مع هذا النوع من الاستعلام.
Remember, no sequel is made for big data.
تذكر أنه لا يوجد تكملة للبيانات الضخمة.
This could be getting back terabytes of data or even more.
قد يكون هذا هو استعادة تيرابايت من البيانات أو أكثر.
Always be aware of the potential performance issues that
كن دائمًا على دراية بقضايا الأداء المحتملة التي
might result from pulling back large amount of data.
قد ينتج عن سحب كمية كبيرة من البيانات.
Our second query here,
استعلامنا الثاني هنا ،
select star from music library where year equals
حدد نجمة من مكتبة الموسيقى حيث تساوي السنة
1965 and the artist's name equals The Beatles.
1965 واسم الفنان يساوي البيتلز.
See here that we're utilizing our clustering column to fetch more specific data.
نرى هنا أننا نستخدم عمود التجميع الخاص بنا لجلب المزيد من البيانات المحددة.
We must use the clustering columns in the order that they were
يجب أن نستخدم أعمدة التجميع بالترتيب الذي كانت عليه
provided in the primary key.
المقدمة في المفتاح الأساسي.
I cannot do a select star from music library where year
لا يمكنني تحديد نجمة من مكتبة الموسيقى حيث السنة
equals 1965 and then album name Let It Be.
يساوي 1965 ثم اسم الألبوم Let It Be.
That will result in an error because we partitioned by
سيؤدي ذلك إلى حدوث خطأ لأننا قسمنا حسب
year and our clustering column was artist's name, not album name.
العام وكان عمود التجميع لدينا هو اسم الفنان ، وليس اسم الألبوم.
Number three our third query,
رقم ثلاثة استعلامنا الثالث ،
select star from music library where year equals
حدد نجمة من مكتبة الموسيقى حيث تساوي السنة
1965 and artist's name equals The Beatles and album name equals Rubber Soul.
1965 واسم الفنان يساوي فرقة البيتلز واسم الألبوم يساوي "الروح المطاطية".
In this case, we will be getting back one row of information in our table.
في هذه الحالة ، سنعيد صفًا واحدًا من المعلومات في جدولنا.
I have used my partition key and all my clustering columns to fetch the data.
لقد استخدمت مفتاح القسم وكل أعمدة التجميع الخاصة بي لجلب البيانات.
So, here's an example of the WHERE clause,
إذن ، هذا مثال على عبارة WHERE ،
select star from music library where year equals
حدد نجمة من مكتبة الموسيقى حيث تساوي السنة
1965 and artist's name equals The Beatles and album name equals Rubber Soul.
1965 واسم الفنان يساوي فرقة البيتلز واسم الألبوم يساوي "الروح المطاطية".
Then we get back to that one row that we discussed.
ثم نعود إلى ذلك الصف الذي ناقشناه.
Select star from table.
حدد نجمة من الجدول.
The WHERE clause must be included in our executed query.
يجب تضمين جملة WHERE في استعلامنا الذي تم تنفيذه.
It is recommended that one partition be queried at a time for performance implications.
من المستحسن أن يتم الاستعلام عن قسم واحد في كل مرة من أجل الآثار المترتبة على الأداء.
It is possible to do a select star from table without
من الممكن تحديد نجمة من الجدول بدونها
the WHERE clause if you add a configuration called ALLOW FILTERING to your query.
عبارة WHERE إذا قمت بإضافة تكوين يسمى ALLOW FILTERING إلى الاستعلام الخاص بك.
This is risky but available and absolutely necessary.
هذا محفوف بالمخاطر ولكنه متاح وضروري للغاية.
They should be done with extreme caution.
يجب أن يتم ذلك بحذر شديد.
I actually will not even provide the syntax for you but it is available to you.
أنا في الواقع لن أقدم لك بناء الجملة ولكنه متاح لك.
No sequel is all about big data and high-performance.
لا توجد تكملة تتعلق بالبيانات الضخمة والأداء العالي.
Keep those factors in mind when performing queries.
ضع هذه العوامل في الاعتبار عند إجراء الاستعلامات.
Thousands of nodes systems exist of Apache Cassandra and select star on
الآلاف من أنظمة العقد موجودة في Apache Cassandra وحدد star on
that system will be trying to pull all the data to the client from thousands of nodes.
سيحاول هذا النظام سحب جميع البيانات إلى العميل من آلاف العقد.
This is called a full table scan.
وهذا ما يسمى بفحص الجدول الكامل.
Best case, would that it'd be extremely slow.
أفضل حالة ، هل سيكون بطيئًا للغاية.
Worst case, it could bring down your system.
أسوأ الحالات ، يمكن أن يؤدي إلى انهيار نظامك.
Adding the WHERE clause we'll make sure this doesn't happen and
عند إضافة جملة WHERE ، سنتأكد من عدم حدوث ذلك و
you're serving the requests with low latency and high performance.
أنت تخدم الطلبات بزمن انتقال منخفض وأداء عالٍ.
All right. Demo four.
حسنا. تجريبي أربعة.
Let's focus more on this WHERE clause.
دعونا نركز أكثر على بند WHERE.
We're going to go and open our Jupyter notebook.
سنذهب ونفتح دفتر Jupyter الخاص بنا.
Lesson three, demo four,
الدرس الثالث ، العرض التوضيحي الرابع ،
and using the WHERE clause.
واستخدام جملة WHERE.
In this demo, we're going to walk through the basics
في هذا العرض التوضيحي ، سنستعرض الأساسيات
of using the WHERE clause in Apache Cassandra.
من استخدام جملة WHERE في Apache Cassandra.
We're going to import our library,
سنقوم باستيراد مكتبتنا ،
connect to our cluster,
الاتصال بمجموعتنا ،
create our key space if it does not exists,
إنشاء مساحتنا الرئيسية إذا لم تكن موجودة ،
connect to our key space, and there we go.
الاتصال بمساحتنا الرئيسية ، وها نحن ذا.
Let's imagine we'd like to start creating a new music library of albums.
لنتخيل أننا نرغب في البدء في إنشاء مكتبة موسيقية جديدة من الألبومات.
We want to ask four questions of our data.
نريد أن نطرح أربعة أسئلة من بياناتنا.
Give me every album in my music library that was released in a given year.
أعطني كل ألبوم في مكتبتي الموسيقية تم إصداره في عام معين.
Select star from music library where year equals blank.
حدد نجمة من مكتبة الموسيقى حيث تساوي السنة فارغة.
Give me the album that is in my music library
أعطني الألبوم الموجود في مكتبتي الموسيقية
that was released in a given year by The Beatles.
التي تم إصدارها في عام معين بواسطة فريق البيتلز.
Select star from music library where year
حدد نجمة من مكتبة الموسيقى حيث السنة
equals a particular year that you choose and artist name.
يساوي سنة معينة تختارها واسم الفنان.
In this case, we're choosing The Beatles.
في هذه الحالة ، نختار فرقة البيتلز.
Give me all the albums released in a given year, in a given location.
أعطني جميع الألبومات التي تم إصدارها في عام معين ، في مكان معين.
Select star for music library where year equals 1970 and location equals Liverpool.
حدد نجمة لمكتبة الموسيقى حيث العام يساوي 1970 والموقع يساوي ليفربول.
Give me a city that the album Let It Be was recorded.
أعطني مدينة سجل فيها الألبوم Let It Be.
Select city from music library where year equals 1970,
اختر المدينة من مكتبة الموسيقى حيث العام يساوي 1970 ،
and artist name The Beatles,
واسم الفنان فريق البيتلز ،
and album name Let It Be.
واسم الألبوم Let It Be.
Here's a collection of our data,
فيما يلي مجموعة من بياناتنا ،
similar to that data that we've seen before in other demos and exercises.
على غرار تلك البيانات التي رأيناها من قبل في العروض التوضيحية والتمارين الأخرى.
How should we model this data?
كيف يمكننا نمذجة هذه البيانات؟
Again, every time I start these demos,
مرة أخرى ، في كل مرة أبدأ فيها هذه العروض التوضيحية ،
that's what I start you with because that's what we have to be thinking about.
هذا ما أبدأ به لأن هذا ما يجب أن نفكر فيه.
How should I model this data knowing my queries in advance?
كيف يمكنني نمذجة هذه البيانات بمعرفة استفساراتي مقدمًا؟
What should be our primary key and our partition key?
ما الذي يجب أن يكون مفتاحنا الأساسي ومفتاح القسم الخاص بنا؟
Since our data is looking for year, let's start with that.
نظرًا لأن بياناتنا تبحث عن عام ، فلنبدأ بذلك.
From there, we'll add clustering columns on artist name and album name.
من هناك ، سنضيف أعمدة مجمعة على اسم الفنان واسم الألبوم.
So, let's create our music library,
فلننشئ مكتبة الموسيقى الخاصة بنا ،
year, artist name, album name, and city.
السنة واسم الفنان واسم الألبوم والمدينة.
We're going to partition by year.
سنقوم بالتقسيم حسب السنة.
We're going to use a clustering column for artist name and album name.
سنستخدم عمود تجميع لاسم الفنان واسم الألبوم.
Let's insert our data into the table.
دعنا ندخل بياناتنا في الجدول.
Again, very similar to what you've seen before.
مرة أخرى ، مشابه جدًا لما رأيته من قبل.
Let's validate our data model with our four queries.
دعنا نتحقق من صحة نموذج البيانات لدينا من خلال استعلاماتنا الأربعة.
Select star from music library where year equals 1970.
اختر نجمة من مكتبة الموسيقى حيث العام يساوي 1970.
So, I get 1970, The Beatles,
حسنًا ، حصلت على عام 1970 ، فريق البيتلز ،
and 1970, The Carpenters.
و 1970 ، النجارون.
Success, it worked.
النجاح ، لقد نجح.
Let's try our second query.
لنجرب استعلامنا الثاني.
Select star from music library where year equals 1970.
اختر نجمة من مكتبة الموسيقى حيث العام يساوي 1970.
I think I want to bring up a point here.
أعتقد أنني أريد أن أتحدث عن نقطة هنا.
So, as we've been talking about one query per one table,
لذلك ، نظرًا لأننا كنا نتحدث عن استعلام واحد لكل جدول ،
which is a wonderful way to do data modeling.
وهي طريقة رائعة لعمل نمذجة البيانات.
But at the same time,
و لكن في نفس الوقت،
you can only do one query per one table.
يمكنك إجراء استعلام واحد فقط لكل جدول واحد.
You can do more than one type of query.
يمكنك عمل أكثر من نوع واحد من الاستعلام.
But this case, we have both.
لكن في هذه الحالة ، لدينا كلاهما.
But in that case, you can do more than one type of
ولكن في هذه الحالة ، يمكنك القيام بأكثر من نوع واحد من ملفات
query like we're doing here with year equals
الاستعلام كما نفعل هنا مع عام يساوي
1970 and year is equal 1970 and artist name equals The Beatles. You can't do that.
1970 وعام يساوي 1970 واسم الفنان يساوي البيتلز. لا يمكنك فعل ذلك.
But you're just adding more of
لكنك تضيف المزيد من
the clustering columns and making your results more specific.
تجميع الأعمدة وجعل نتائجك أكثر تحديدًا.
So, it's a different query but it's still utilizing the same data model.
لذلك ، إنه استعلام مختلف ولكنه لا يزال يستخدم نفس نموذج البيانات.
I hope that's clear. So, let's try that.
آمل أن يكون هذا واضحًا. لذا ، دعونا نجرب ذلك.
Select star from music library where year equals
حدد نجمة من مكتبة الموسيقى حيث تساوي السنة
1970 and the artist name equals The Beatles.
1970 واسم الفنان يساوي البيتلز.
Awesome. I got back my result.
رائع. حصلت على نتيجتي.
It worked. Let's try the third query.
انها عملت. لنجرب الاستعلام الثالث.
Select star from music library where year equals 1970 and location equals Liverpool.
اختر نجمة من مكتبة الموسيقى حيث العام يساوي 1970 والموقع يساوي ليفربول.
An error, a very ugly error at that.
خطأ ، خطأ قبيح للغاية في ذلك.
Undefined column name location,
موقع اسم العمود غير محدد ،
not very clear. But what does it mean?
ليس واضحا جدا. و لكن ماذا يعني ذلك؟
Error. You can not try to access a column or
خطأ. لا يمكنك محاولة الوصول إلى عمود أو
clustering columns if you have not used the other defined clustering columns.
تجميع الأعمدة إذا لم تكن قد استخدمت أعمدة المجموعات المحددة الأخرى.
Let's go back to where we created our table.
دعنا نعود إلى حيث أنشأنا طاولتنا.
So, here, we have our partition key of year,
إذن ، لدينا هنا مفتاح التقسيم للعام ،
our clustering column of artist name,
عمود التجميع لدينا من اسم الفنان ،
and our clustering column of album name.
وعمودنا التجميعي لاسم الألبوم.
You have to utilize to do a query.
عليك أن تستخدم لعمل استعلام.
You have to use these in order.
يجب عليك استخدام هذه بالترتيب.
Also, if we wanted to use and city,
أيضًا ، إذا أردنا استخدام والمدينة ،
we have to use it after we've used all of these columns.
علينا استخدامه بعد أن استخدمنا كل هذه الأعمدة.
So, year, artist name,
إذن ، السنة ، اسم الفنان ،
album name, and city.
اسم الألبوم والمدينة.
We can't just use any column.
لا يمكننا استخدام أي عمود فقط.
We have to use all the clustering columns in order.
علينا استخدام جميع أعمدة التجميع بالترتيب.
That's why we got a failure.
لهذا السبب حصلنا على فشل.
That value is to be expected.
هذه القيمة متوقعة.
So, let's see if we can do this in a different way.
لذا ، دعنا نرى ما إذا كان بإمكاننا القيام بذلك بطريقة مختلفة.
Select city from music library where year equals 1970,
اختر المدينة من مكتبة الموسيقى حيث العام يساوي 1970 ،
and artist name equals The Beatles,
واسم الفنان يساوي البيتلز ،
and album name Let It Be.
واسم الألبوم Let It Be.
So, again, we're utilizing all of our clustering columns in the query,
لذا ، مرة أخرى ، نستخدم جميع أعمدة المجموعات في الاستعلام ،
and we get back Liverpool.
ونعود ليفربول.
So, for the sake of the demo,
لذلك ، من أجل العرض التوضيحي ،
I will drop the tables.
سوف أسقط الطاولات.
I got an error there, how interesting.
لقد حصلت على خطأ هناك ، كم هو مثير للاهتمام.
That's because I didn't create,
هذا لأنني لم أصنع ،
I've already dropped music library one.
لقد أسقطت بالفعل مكتبة الموسيقى واحدة.
Yeah. Unconfigured table, music library one.
نعم. طاولة غير مهيأة ، مكتبة موسيقى واحدة.
That's just a typo. I didn't need this.
هذا مجرد خطأ مطبعي. لم أكن بحاجة إلى هذا.
Then, we'll close our connection. Awesome.
بعد ذلك ، سنغلق اتصالنا. رائع.
All right. So we're ready to wrap up.
حسنا. لذلك نحن على استعداد للختام.
We've gone through all our demos and all our exercises.
لقد مررنا بجميع عروضنا وجميع تماريننا.
So what did we learn in this lesson?
إذن ماذا تعلمنا في هذا الدرس؟
We learned about the basics of distributed database design and why
تعلمنا عن أساسيات تصميم قاعدة البيانات الموزعة ولماذا
the affects of that will affect our data modeling decisions.
ستؤثر تأثيرات ذلك على قراراتنا المتعلقة بنمذجة البيانات.
NoSQL is already optimized for rights.
تم بالفعل تحسين NoSQL للحقوق.
So we must model our data to allow reads to be fast.
لذلك يجب علينا نمذجة بياناتنا للسماح للقراءات أن تكون سريعة.
We must have our queries and model the tables to our queries.
يجب أن يكون لدينا استعلاماتنا ونمذجة الجداول لاستفساراتنا.
Always data model with queries in mind.
دائما نموذج البيانات مع وضع الاستفسارات في الاعتبار.
Importance of denormalization: We learned why
أهمية إلغاء التطبيع: لقد تعلمنا السبب
we must denormalize to allow for fast reads.
يجب أن نغير الوضع الطبيعي للسماح بقراءات سريعة.
We learned about Apache Cassandra and how it is a very popular NoSQL database.
لقد تعلمنا عن Apache Cassandra وكيف أنها قاعدة بيانات NoSQL شائعة جدًا.
Then it's also used in a number of very high profile companies.
ثم يتم استخدامه أيضًا في عدد من الشركات البارزة جدًا.
We learned about the primary key,
تعلمنا عن المفتاح الأساسي ،
partition key, and clustering columns.
مفتاح التقسيم وتجميع الأعمدة.
We learned about the primary key and how that is made up of partition key,
لقد تعلمنا عن المفتاح الأساسي وكيف يتكون من مفتاح التقسيم ،
which distributes the data,
الذي يوزع البيانات ،
and the clustering column, which orders the data.
وعمود التجميع الذي يطلب البيانات.
We learned about the where clause as we must think about our queries,
لقد تعلمنا عن عبارة أين حيث يجب أن نفكر في استفساراتنا ،
and that we have limitations on select star.
وأن لدينا قيودًا على اختيار النجوم.
So let's wrap up our course.
لذلك دعونا نختتم دورتنا.
What did we learn in lesson one, two and three?
ماذا تعلمنا في الدرس الأول والثاني والثالث؟
In lesson one, we learned about the fundamentals of when to use
في الدرس الأول ، تعلمنا عن أساسيات وقت الاستخدام
relational databases and when to use a non-relational database.
قواعد البيانات العلائقية ومتى تستخدم قاعدة بيانات غير علائقية.
We learned about their strength and their weaknesses.
تعلمنا عن قوتهم ونقاط ضعفهم.
In lesson two, we learned about the fundamentals
في الدرس الثاني ، تعلمنا الأساسيات
of how to do relational database modeling.
حول كيفية القيام بنمذجة قواعد البيانات العلائقية.
We focused on normalization and moving data into third normal form.
ركزنا على التطبيع ونقل البيانات إلى النموذج العادي الثالث.
We also learned about when to denormalize even in relational data modeling.
تعلمنا أيضًا متى يجب إلغاء التطابق حتى في نمذجة البيانات العلائقية.
We learn when to use fact and dimension tables and how
نتعلم متى نستخدم جداول الحقائق والأبعاد وكيف
those come together to create a star schema which is highly used in industry.
يجتمع هؤلاء معًا لإنشاء مخطط نجمي يستخدم بشكل كبير في الصناعة.
In lesson three, we learned about the importance of
في الدرس الثالث ، تعلمنا عن أهمية
denormalization for NoSQL database modeling.
عدم التطابق لنمذجة قاعدة بيانات NoSQL.
We learned that tables must be denormalized as there are no joints in NoSQL databases.
لقد تعلمنا أنه يجب إلغاء تسوية الجداول نظرًا لعدم وجود مفاصل في قواعد بيانات NoSQL.
We learned about the fundamentals of NoSQL database modeling that focus on queries first.
لقد تعلمنا عن أساسيات نمذجة قاعدة بيانات NoSQL التي تركز على الاستعلامات أولاً.
We discussed how to create the primary key
ناقشنا كيفية إنشاء المفتاح الأساسي
out of the partition key and clustering columns.
من مفتاح القسم وتجميع الأعمدة.
We talked about the basics of distributed database design to help us
تحدثنا عن أساسيات تصميم قاعدة البيانات الموزعة لمساعدتنا
understand why data modeling is different from NoSQL database modeling.
فهم سبب اختلاف نمذجة البيانات عن نمذجة قاعدة بيانات NoSQL.
Remember, the critical thinking skills you employ when you do data modeling is
تذكر أن مهارات التفكير النقدي التي تستخدمها عندما تقوم بنمذجة البيانات هي
a skill that is and should be independent of the type of database you're working with.
مهارة مستقلة عن نوع قاعدة البيانات التي تعمل بها ويجب أن تكون كذلك.
Once you have these skills,
بمجرد حصولك على هذه المهارات ،
you'll be able to transfer these skills to any database you are working with.
ستتمكن من نقل هذه المهارات إلى أي قاعدة بيانات تعمل بها.
The skill is universal,
المهارة عالمية ،
but data models between systems should be carefully
ولكن يجب أن تكون نماذج البيانات بين الأنظمة بعناية
reviewed before doing any kind of blind copy paste.
تمت مراجعتها قبل عمل أي نوع من أنواع لصق النسخ المخفية.
I've really enjoyed creating these lessons and
لقد استمتعت حقًا بإنشاء هذه الدروس و
sharing my understanding of data modeling with you all.
مشاركة فهمي لنمذجة البيانات معكم جميعًا.
Congrats on finishing this course and thank you.
مبروك على الانتهاء من هذه الدورة وشكرا لك.