Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Won't Do
-
1.2.3, 1.2.4
-
None
-
Vmware 6.7
3 PM and 2 UM with glusterfs and Oracle Linux 7.6.
Description
Hi,
I use the MariaDB Columnstore 1.2.4 with 3 PM and 2 UM.
We have a lot jobs that populate the data into the columnstore using MariaDB Pentaho kettle adapter.
Checking the compression I have the following results:
MariaDB [(none)]> call columnstore_info.compression_ratio();
-------------------
| COMPRESSION_RATIO |
-------------------
| 0.6850:1 |
-------------------
1 row in set (32.621 sec)
Query OK, 0 rows affected (32.621 sec)
MariaDB [(none)]> call columnstore_info.total_usage();
---------------------------------+
| TOTAL_DATA_SIZE | TOTAL_DISK_USAGE |
---------------------------------+
| 199.07 GB | 356.33 GB |
---------------------------------+
1 row in set (25.465 sec)
Query OK, 0 rows affected (25.465 sec)
The compression is always less efficient. Thus continuing the risk of occupying the required space twice. Why is compression (snappy) so inefficient to occupy more space than required?
Thi is the filesystem (GlusterFS) distribution space :
/dev/mapper/glusterfs_dbroot3-brick3 400G 76G 325G 19% /usr/local/mariadb/columnstore/gluster/brick3
/dev/mapper/glusterfs_dbroot2-brick2 400G 79G 322G 20% /usr/local/mariadb/columnstore/gluster/brick2
/dev/mapper/glusterfs_dbroot1-brick1 400G 202G 198G 51% /usr/local/mariadb/columnstore/gluster/brick1
why not distribute the space fairly? ( i use only cpimport).
I've open the post in the google groups :
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/mariadb-columnstore/RZFVO2ufQI4/RpxVs_1UBAAJ
Thanks,
Regards
Nicola Battista
Thanks,
Regards.