> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-fbfa8bee.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> MergeTree مستند إلى Google Cloud Storage (GCS)
# دمج Google Cloud Storage مع ClickHouse
export const Image = ({img, alt, size}) => {
return
;
};
إذا كنت تستخدم ClickHouse Cloud على [Google Cloud](https://cloud.google.com)، فلا تنطبق عليك هذه الصفحة لأن خدماتك تستخدم بالفعل [Google Cloud Storage](https://cloud.google.com/storage). وإذا كنت تبحث عن كيفية تنفيذ `SELECT` أو `INSERT` على بيانات GCS، فيُرجى مراجعة [دالة الجدول `gcs`](/ar/reference/functions/table-functions/gcs).
يدرك ClickHouse أن GCS توفّر حلّ تخزين جذابًا إذا كنت تسعى إلى فصل التخزين عن الحوسبة. ولدعم ذلك، تتوفر إمكانية استخدام GCS كطبقة تخزين لمحرك MergeTree. ويتيح لك هذا الاستفادة من قابلية التوسع والمزايا من حيث التكلفة التي توفّرها GCS، إلى جانب أداء عمليات `insert` و`query` في محرك MergeTree.
## MergeTree المدعوم بـ GCS
### إنشاء قرص
لاستخدام حاوية GCS كقرص، يجب أولاً التصريح بها ضمن إعدادات ClickHouse في ملف داخل `conf.d`. يوضّح المثال أدناه تعريف قرص GCS. يتضمن هذا الإعداد عدة أقسام لإعداد "القرص" في GCS، وذاكرة التخزين المؤقت، والسياسة التي تُحدَّد في استعلامات DDL عند إنشاء الجداول على قرص GCS. ويرد شرح كل منها أدناه.
#### تهيئة التخزين > disks > gcs
يظهر هذا الجزء من التهيئة في القسم المميز، ويحدّد ما يلي:
* نوع القرص هو `s3` لأن واجهة برمجة تطبيقات S3 مستخدمة.
* نقطة النهاية كما توفّرها GCS
* مفتاح HMAC والسرّ الخاصّان بحساب الخدمة
* مسار البيانات الوصفية على القرص المحلي
```xml highlight={5-10} theme={null}
true
s3
https://storage.googleapis.com/BUCKET NAME/FOLDER NAME/
SERVICE ACCOUNT HMAC KEY
SERVICE ACCOUNT HMAC SECRET
/var/lib/clickhouse/disks/gcs/
gcs
```
#### إعدادات التخزين > الأقراص > ذاكرة التخزين المؤقت
يُفعّل مثال الإعدادات الموضّح أدناه ذاكرة تخزين مؤقت في الذاكرة بسعة 10Gi للقرص `gcs`.
```xml highlight={12-17} theme={null}
true
s3
https://storage.googleapis.com/BUCKET NAME/FOLDER NAME/
SERVICE ACCOUNT HMAC KEY
SERVICE ACCOUNT HMAC SECRET
/var/lib/clickhouse/disks/gcs/
cache
gcs
/var/lib/clickhouse/disks/gcs_cache/
10Gi
gcs_cache
```
#### إعدادات التخزين > السياسات > gcs\_main
تتيح سياسات إعدادات التخزين اختيار مكان تخزين البيانات. وتسمح السياسة المبرزة أدناه بتخزين البيانات على القرص `gcs` عبر تحديد السياسة `gcs_main`. على سبيل المثال، `CREATE TABLE ... SETTINGS storage_policy='gcs_main'`.
```xml highlight={14-20} theme={null}
true
s3
https://storage.googleapis.com/BUCKET NAME/FOLDER NAME/
SERVICE ACCOUNT HMAC KEY
SERVICE ACCOUNT HMAC SECRET
/var/lib/clickhouse/disks/gcs/
gcs
```
يمكن العثور على قائمة كاملة بالإعدادات المرتبطة بتعريف هذا القرص [هنا](/ar/reference/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-s3).
### إنشاء جدول
بافتراض أنك قمت بتهيئة القرص لاستخدام حاوية تخزين مع صلاحية الكتابة، ينبغي أن تتمكن من إنشاء جدول كما في المثال أدناه. وللاختصار، نستخدم مجموعة فرعية من أعمدة بيانات سيارات الأجرة في مدينة نيويورك ونرسل البيانات مباشرةً إلى الجدول المدعوم من GCS:
```sql highlight={20} theme={null}
CREATE TABLE trips_gcs
(
`trip_id` UInt32,
`pickup_date` Date,
`pickup_datetime` DateTime,
`dropoff_datetime` DateTime,
`pickup_longitude` Float64,
`pickup_latitude` Float64,
`dropoff_longitude` Float64,
`dropoff_latitude` Float64,
`passenger_count` UInt8,
`trip_distance` Float64,
`tip_amount` Float32,
`total_amount` Float32,
`payment_type` Enum8('UNK' = 0, 'CSH' = 1, 'CRE' = 2, 'NOC' = 3, 'DIS' = 4)
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(pickup_date)
ORDER BY pickup_datetime
SETTINGS storage_policy='gcs_main'
```
```sql theme={null}
INSERT INTO trips_gcs SELECT trip_id, pickup_date, pickup_datetime, dropoff_datetime, pickup_longitude, pickup_latitude, dropoff_longitude, dropoff_latitude, passenger_count, trip_distance, tip_amount, total_amount, payment_type FROM s3('https://ch-nyc-taxi.s3.eu-west-3.amazonaws.com/tsv/trips_{0..9}.tsv.gz', 'TabSeparatedWithNames') LIMIT 1000000;
```
اعتمادًا على العتاد، قد تستغرق عملية الإدراج الأخيرة لمليون صف بضع دقائق حتى تكتمل. يمكنك التحقق من التقدم عبر جدول system.processes. لا تتردد في تعديل عدد الصفوف حتى حد 10 ملايين واستكشاف بعض الاستعلامات النموذجية.
```sql theme={null}
SELECT passenger_count, avg(tip_amount) AS avg_tip, avg(total_amount) AS avg_amount FROM trips_gcs GROUP BY passenger_count;
```
### التعامل مع النسخ المتماثل
يمكن تحقيق النسخ المتماثل باستخدام أقراص GCS عبر محرك الجدول `ReplicatedMergeTree`. راجع دليل [نسخ جزء بيانات واحد متماثلًا عبر منطقتين من GCP باستخدام GCS](#gcs-multi-region) للاطلاع على التفاصيل.
### تعرّف على المزيد
تتوافق [واجهة XML لـ Cloud Storage](https://cloud.google.com/storage/docs/xml-api/overview) مع بعض الأدوات والمكتبات التي تعمل مع خدمات مثل Amazon Simple Storage Service (Amazon S3).
لمزيد من المعلومات حول ضبط سلاسل التنفيذ، راجع [تحسين الأداء](/ar/integrations/connectors/data-ingestion/AWS/integrating-s3-with-clickhouse#s3-optimizing-performance).
## استخدام Google Cloud Storage (GCS)
يُستخدم تخزين الكائنات افتراضيًا في ClickHouse Cloud، لذا لا تحتاج إلى اتباع هذا الإجراء إذا كنت تستخدم ClickHouse Cloud.
### تخطيط النشر
كُتب هذا الدليل العملي لشرح عملية نشر ClickHouse مكرّر يعمل على Google Cloud ويستخدم Google Cloud Storage (GCS) بوصفه «type» لقرص التخزين في ClickHouse.
في هذا الدليل العملي، ستنشر عقد ClickHouse server على أجهزة VM في Google Cloud Engine، مع حاوية GCS مخصّص للتخزين لكل عقدة. ويجري تنسيق النسخ المتماثل بواسطة مجموعة من عقد ClickHouse Keeper، والتي تُنشر أيضًا كأجهزة VM.
متطلبات نموذجية للتوافر العالي:
* عقدتا ClickHouse server في منطقتين من GCP
* حاوية GCS عدد 2، منشوران في المنطقتين نفسيهما اللتين توجد فيهما عقدتا ClickHouse server
* ثلاث عقد ClickHouse Keeper، اثنتان منها منشورتان في المنطقتين نفسيهما اللتين توجد فيهما عقدتا ClickHouse server. ويمكن أن تكون العقدة الثالثة في المنطقة نفسها لإحدى أول عقدتَي Keeper، ولكن ضمن نطاق توافر مختلف.
يتطلب ClickHouse Keeper عقدتين ليعمل، لذا يلزم وجود ثلاث عقد لتحقيق التوافر العالي.
### تجهيز الآلات الافتراضية
قم بنشر خمس آلات افتراضية في ثلاث مناطق:
| المنطقة | ClickHouse Server | حاوية | ClickHouse Keeper |
| ------- | ----------------- | ------------------- | ----------------- |
| 1 | `chnode1` | `bucket_regionname` | `keepernode1` |
| 2 | `chnode2` | `bucket_regionname` | `keepernode2` |
| 3 `*` | | | `keepernode3` |
`*` يمكن أن تكون هذه منطقة توافر مختلفة ضمن نفس المنطقة الخاصة بـ 1 أو 2.
#### نشر ClickHouse
قم بنشر ClickHouse على مضيفين؛ وفي إعدادات المثال يُسمَّيان `chnode1` و`chnode2`.
ضع `chnode1` في إحدى مناطق GCP، و`chnode2` في منطقة أخرى. في هذا الدليل، تُستخدم `us-east1` و`us-east4` لكلٍّ من الأجهزة الافتراضية في Compute Engine وحاويات GCS.
لا تبدأ `clickhouse server` إلا بعد إعداده. اكتفِ بتثبيته فقط.
ارجع إلى [تعليمات التثبيت](/ar/get-started/setup/install) عند تنفيذ خطوات النشر على عُقد خادم ClickHouse.
#### نشر ClickHouse Keeper
انشر ClickHouse Keeper على ثلاثة مضيفين. وفي نماذج الإعداد هذه، تُسمّى `keepernode1` و`keepernode2` و`keepernode3`. يمكن نشر `keepernode1` في المنطقة نفسها التي يوجد فيها `chnode1`، و`keepernode2` مع `chnode2`، و`keepernode3` في أيٍّ من المنطقتين، ولكن في منطقة توافر مختلفة عن عقدة ClickHouse في تلك المنطقة.
راجع [تعليمات التثبيت](/ar/get-started/setup/install) عند تنفيذ خطوات النشر على عقد ClickHouse Keeper.
### إنشاء حاويتين
سيُوضَع خادما ClickHouse في منطقتين مختلفتين لتحقيق التوفّر العالي. وستكون لكلٍّ منهما حاوية GCS في المنطقة نفسها.
في **Cloud Storage > Buckets**، اختر **CREATE BUCKET**. في هذا الدليل العملي، ستُنشأ حاويتان: واحدة في `us-east1` وأخرى في `us-east4`. يجب أن تكون الحاويتان ضمن منطقة واحدة، وبفئة التخزين القياسية، وغير عامّتَين. وعندما يُطلب منك ذلك، فعِّل منع الوصول العام. لا تُنشئ مجلدات، إذ سيُنشئها ClickHouse عند الكتابة إلى وحدة التخزين.
إذا كنت بحاجة إلى إرشادات خطوة بخطوة لإنشاء حاويات GCS ومفتاح HMAC، فوسِّع **إنشاء حاويات GCS ومفتاح HMAC** وتابع:
### ch\_bucket\_us\_east1
### ch\_bucket\_us\_east4
### إنشاء مفتاح وصول
### إنشاء مفتاح HMAC وقيمة سرية لحساب خدمة
افتح **Cloud Storage > Settings > Interoperability** ثم اختر إما **Access key** موجودًا أو **CREATE A KEY FOR A SERVICE ACCOUNT**. يشرح هذا الدليل مسار إنشاء مفتاح جديد لحساب خدمة جديد.
### إضافة حساب خدمة جديد
إذا كان هذا مشروعًا لا يحتوي على أي حساب خدمة موجود، فاختر **CREATE NEW ACCOUNT**.
هناك ثلاث خطوات لإنشاء حساب الخدمة. في الخطوة الأولى، امنح الحساب اسمًا مناسبًا ومعرّفًا ووصفًا.
في مربع حوار إعدادات Interoperability، يُوصى بدور IAM **Storage Object Admin**؛ حدّد هذا الدور في الخطوة الثانية.
الخطوة الثالثة اختيارية ولا تُستخدم في هذا الدليل. يمكنك منح المستخدمين هذه الامتيازات وفقًا لسياساتك.
سيُعرض مفتاح HMAC الخاص بحساب الخدمة. احفظ هذه المعلومات، إذ ستُستخدم في إعداد ClickHouse.
### تهيئة ClickHouse Keeper
تستخدم جميع عقد ClickHouse Keeper ملف التهيئة نفسه، باستثناء السطر `server_id` (أول سطر مميز أدناه). عدّل الملف بإدراج أسماء المضيفين الخاصة بخوادم ClickHouse Keeper لديك، وعلى كل خادم اضبط `server_id` بحيث يطابق إدخال `server` المناسب في `raft_configuration`. ونظرًا لأن `server_id` في هذا المثال مضبوط على `3`، فقد ميّزنا الأسطر المطابقة في `raft_configuration`.
* عدّل الملف باستخدام أسماء المضيفين لديك، وتأكد من إمكانية حلّها من عُقد ClickHouse server وعُقد Keeper
* انسخ الملف إلى موقعه (`/etc/clickhouse-keeper/keeper_config.xml` على كل خوادم Keeper)
* عدّل `server_id` على كل جهاز، استنادًا إلى رقم الإدخال الخاص به في `raft_configuration`
```xml title=/etc/clickhouse-keeper/keeper_config.xml highlight={12,33-37} theme={null}
trace
/var/log/clickhouse-keeper/clickhouse-keeper.log
/var/log/clickhouse-keeper/clickhouse-keeper.err.log
1000M
3
0.0.0.0
9181
3
/var/lib/clickhouse/coordination/log
/var/lib/clickhouse/coordination/snapshots
10000
30000
warning
1
keepernode1.us-east1-b.c.clickhousegcs-374921.internal
9234
2
keepernode2.us-east4-c.c.clickhousegcs-374921.internal
9234
3
keepernode3.us-east5-a.c.clickhousegcs-374921.internal
9234
```
### تهيئة خادم ClickHouse
**أفضل الممارسات**
ستطلب منك بعض الخطوات في هذا الدليل وضع ملف تهيئة في `/etc/clickhouse-server/config.d/`. هذا هو الموقع الافتراضي في أنظمة Linux لملفات تجاوز التهيئة. عند وضع هذه الملفات في ذلك الدليل، يدمج ClickHouse محتواها مع التهيئة الافتراضية. ومن خلال وضع هذه الملفات في الدليل `config.d`، ستتجنب فقدان تهيئتك أثناء الترقية.
#### الشبكة
بشكل افتراضي، يستمع ClickHouse على واجهة loopback، وفي إعداد يستخدم النسخ المتماثل تكون الحاجة إلى الاتصال الشبكي بين الأجهزة ضرورية. اجعله يستمع على جميع الواجهات:
```xml title=/etc/clickhouse-server/config.d/network.xml theme={null}
0.0.0.0
```
#### خوادم ClickHouse Keeper البعيدة
تتم إدارة النسخ المتماثل بواسطة ClickHouse Keeper. يحدِّد ملف التهيئة هذا عُقد ClickHouse Keeper بحسب اسم المضيف ورقم المنفذ.
* عدِّل أسماء المضيفين لتطابق خوادم Keeper لديك
```xml title=/etc/clickhouse-server/config.d/use-keeper.xml theme={null}
keepernode1.us-east1-b.c.clickhousegcs-374921.internal
9181
keepernode2.us-east4-c.c.clickhousegcs-374921.internal
9181
keepernode3.us-east5-a.c.clickhousegcs-374921.internal
9181
```
#### خوادم ClickHouse البعيدة
يحدّد هذا الملف اسم المضيف والمنفذ لكل خادم ClickHouse في العنقود. يحتوي ملف التكوين الافتراضي على تعريفات نموذجية للعناقيد، ولعرض العناقيد المكتمل تكوينها فقط، أُضيف الوسم `replace="true"` إلى الإدخال `remote_servers` بحيث إنه عند دمج هذا التكوين مع التكوين الافتراضي، يستبدل قسم `remote_servers` بدلًا من الإضافة إليه.
* حرّر الملف بإدخال أسماء المضيفين الخاصة بك، وتأكد من إمكانية حلّها من عُقد خادم ClickHouse
```xml title=/etc/clickhouse-server/config.d/remote-servers.xml theme={null}
chnode1.us-east1-b.c.clickhousegcs-374921.internal
9000
chnode2.us-east4-c.c.clickhousegcs-374921.internal
9000
```
#### تحديد هوية النسخة المتماثلة
يحدّد هذا الملف الإعدادات المرتبطة بمسار ClickHouse Keeper. وتحديدًا، وحدات الماكرو المستخدمة لتحديد النسخة المتماثلة التي تنتمي إليها البيانات. على أحد الخوادم، يجب تحديد النسخة المتماثلة على أنها `replica_1`، وعلى الخادم الآخر `replica_2`. يمكن تغيير الأسماء؛ فاستنادًا إلى مثالنا حيث تُخزَّن إحدى النسختين المتماثلتين في ساوث كارولاينا والأخرى في شمال فرجينيا، يمكن أن تكون القيم `carolina` و`virginia`؛ فقط تأكد من أنها مختلفة على كل جهاز.
```xml title=/etc/clickhouse-server/config.d/macros.xml highlight={8} theme={null}
/clickhouse/task_queue/ddl
cluster_1S_2R
1
replica_1
```
#### التخزين في GCS
يتضمن إعداد التخزين في ClickHouse كلاً من `disks` و`policies`. يحمل الـ `disk` الذي يجري إعداده أدناه الاسم `gcs`، وهو من `type` `s3`. ويكون النوع `s3` لأن ClickHouse يتعامل مع حاوية GCS كما لو أنه حاوية AWS S3. ستحتاج إلى نسختين من هذا الإعداد، واحدة لكل عقدة من عقد ClickHouse server.
يجب إجراء عمليات الاستبدال التالية في الإعداد أدناه.
تختلف عمليات الاستبدال هذه بين عقدتي ClickHouse server:
* يجب ضبط `REPLICA 1 BUCKET` على اسم الـ حاوية الموجود في نفس الـ Region الخاصة بالخادم
* يجب تغيير `REPLICA 1 FOLDER` إلى `replica_1` على أحد الخادمين، وإلى `replica_2` على الخادم الآخر
عمليات الاستبدال التالية مشتركة بين العقدتين:
* يجب ضبط `access_key_id` على HMAC Key الذي تم إنشاؤه سابقًا
* يجب ضبط `secret_access_key` على HMAC Secret الذي تم إنشاؤه سابقًا
```xml title=/etc/clickhouse-server/config.d/storage.xml theme={null}
true
s3
https://storage.googleapis.com/REPLICA 1 BUCKET/REPLICA 1 FOLDER/
SERVICE ACCOUNT HMAC KEY
SERVICE ACCOUNT HMAC SECRET
/var/lib/clickhouse/disks/gcs/
cache
gcs
/var/lib/clickhouse/disks/gcs_cache/
10Gi
gcs
```
### تشغيل ClickHouse Keeper
استخدم الأوامر المناسبة لنظام التشغيل لديك، على سبيل المثال:
```bash theme={null}
sudo systemctl enable clickhouse-keeper
sudo systemctl start clickhouse-keeper
sudo systemctl status clickhouse-keeper
```
#### التحقّق من حالة ClickHouse Keeper
أرسل الأوامر إلى ClickHouse Keeper باستخدام `netcat`. على سبيل المثال، يُرجع `mntr` حالة عنقود ClickHouse Keeper. وإذا شغّلت الأمر على كل عقدة من عقد Keeper، فسترى أن إحداها هي القائد، وأن العقدتين الأخريين تابعتان:
```bash theme={null}
echo mntr | nc localhost 9181
```
```response highlight={7-9,18-19} theme={null}
zk_version v22.7.2.15-stable-f843089624e8dd3ff7927b8a125cf3a7a769c069
zk_avg_latency 0
zk_max_latency 11
zk_min_latency 0
zk_packets_received 1783
zk_packets_sent 1783
zk_num_alive_connections 2
zk_outstanding_requests 0
zk_server_state leader
zk_znode_count 135
zk_watch_count 8
zk_ephemerals_count 3
zk_approximate_data_size 42533
zk_key_arena_size 28672
zk_latest_snapshot_size 0
zk_open_file_descriptor_count 182
zk_max_file_descriptor_count 18446744073709551615
zk_followers 2
zk_synced_followers 2
```
### تشغيل ClickHouse server
على `chnode1` و`chnode`، شغّل:
```bash theme={null}
sudo service clickhouse-server start
```
```bash theme={null}
sudo service clickhouse-server status
```
### التحقق
#### تحقّق من تهيئة القرص
يجب أن يتضمّن `system.disks` سجلات لكل قرص:
* default
* gcs
* cache
```sql theme={null}
SELECT *
FROM system.disks
FORMAT Vertical
```
```response theme={null}
Row 1:
──────
name: cache
path: /var/lib/clickhouse/disks/gcs/
free_space: 18446744073709551615
total_space: 18446744073709551615
unreserved_space: 18446744073709551615
keep_free_space: 0
type: s3
is_encrypted: 0
is_read_only: 0
is_write_once: 0
is_remote: 1
is_broken: 0
cache_path: /var/lib/clickhouse/disks/gcs_cache/
Row 2:
──────
name: default
path: /var/lib/clickhouse/
free_space: 6555529216
total_space: 10331889664
unreserved_space: 6555529216
keep_free_space: 0
type: local
is_encrypted: 0
is_read_only: 0
is_write_once: 0
is_remote: 0
is_broken: 0
cache_path:
Row 3:
──────
name: gcs
path: /var/lib/clickhouse/disks/gcs/
free_space: 18446744073709551615
total_space: 18446744073709551615
unreserved_space: 18446744073709551615
keep_free_space: 0
type: s3
is_encrypted: 0
is_read_only: 0
is_write_once: 0
is_remote: 1
is_broken: 0
cache_path:
3 rows in set. Elapsed: 0.002 sec.
```
#### تحقّق من أن الجداول التي أُنشئت على العنقود قد أُنشئت أيضًا على كلتا العقدتين
```sql highlight={1,18} theme={null}
create table trips on cluster 'cluster_1S_2R' (
`trip_id` UInt32,
`pickup_date` Date,
`pickup_datetime` DateTime,
`dropoff_datetime` DateTime,
`pickup_longitude` Float64,
`pickup_latitude` Float64,
`dropoff_longitude` Float64,
`dropoff_latitude` Float64,
`passenger_count` UInt8,
`trip_distance` Float64,
`tip_amount` Float32,
`total_amount` Float32,
`payment_type` Enum8('UNK' = 0, 'CSH' = 1, 'CRE' = 2, 'NOC' = 3, 'DIS' = 4))
ENGINE = ReplicatedMergeTree
PARTITION BY toYYYYMM(pickup_date)
ORDER BY pickup_datetime
SETTINGS storage_policy='gcs_main'
```
```response theme={null}
┌─host───────────────────────────────────────┬─port─┬─status─┬─error─┬─num_hosts_remaining─┬─num_hosts_active─┐
│ chnode2.us-east4-c.c.gcsqa-375100.internal │ 9000 │ 0 │ │ 1 │ 1 │
└────────────────────────────────────────────┴──────┴────────┴───────┴─────────────────────┴──────────────────┘
┌─host───────────────────────────────────────┬─port─┬─status─┬─error─┬─num_hosts_remaining─┬─num_hosts_active─┐
│ chnode1.us-east1-b.c.gcsqa-375100.internal │ 9000 │ 0 │ │ 0 │ 0 │
└────────────────────────────────────────────┴──────┴────────┴───────┴─────────────────────┴──────────────────┘
2 rows in set. Elapsed: 0.641 sec.
```
#### تحقّق من إمكانية إدخال البيانات
```sql theme={null}
INSERT INTO trips SELECT
trip_id,
pickup_date,
pickup_datetime,
dropoff_datetime,
pickup_longitude,
pickup_latitude,
dropoff_longitude,
dropoff_latitude,
passenger_count,
trip_distance,
tip_amount,
total_amount,
payment_type
FROM s3('https://ch-nyc-taxi.s3.eu-west-3.amazonaws.com/tsv/trips_{0..9}.tsv.gz', 'TabSeparatedWithNames')
LIMIT 1000000
```
#### تحقّق من أن سياسة التخزين `gcs_main` مستخدمة للجدول.
```sql theme={null}
SELECT
engine,
data_paths,
metadata_path,
storage_policy,
formatReadableSize(total_bytes)
FROM system.tables
WHERE name = 'trips'
FORMAT Vertical
```
```response theme={null}
Row 1:
──────
engine: ReplicatedMergeTree
data_paths: ['/var/lib/clickhouse/disks/gcs/store/631/6315b109-d639-4214-a1e7-afbd98f39727/']
metadata_path: /var/lib/clickhouse/store/e0f/e0f3e248-7996-44d4-853e-0384e153b740/trips.sql
storage_policy: gcs_main
formatReadableSize(total_bytes): 36.42 MiB
1 row in set. Elapsed: 0.002 sec.
```
#### تحقّق في Google Cloud Console
عند النظر إلى حاويات التخزين، سترى أنه تم إنشاء مجلد في كل حاوية بالاسم المستخدم في ملف التكوين `storage.xml`. وسِّع المجلدات وسترى العديد من الملفات التي تمثل أقسام البيانات.
#### الحاوية الخاصة بالنسخة المتماثلة الأولى
#### حاوية النسخة المتماثلة الثانية