0

So I have this database (Size 3.1Gb total), but this is due to one specific table I've got, containing A LOT of console output text, from some test runs. The table itself is 2.7Gb, and I was wondering if there could be another solution for this table, so the database would get a lot smaller? It's getting a bit anoying to backup the database or even make a copy of the database to a playground, because it's so big this table.

The Table is this one

enter image description here

Would it be better to delete this table and make all the LogTextData <- LongText, be stored in a PDF, instead of the database? (Then I can't backup this data tho...) Do anyone have an idea on how to make this table smaller, or another solution? I'm open for suggestions, to make this table smaller.

The way this console log data gets imported to the database is by Python scipts, so I have fully access to other python solutions, if there is any.

I could each day make a gzip of all the created logfiles, and then transfer them to another location (Cloud)? The database already gets transfered to another location, IF the server breaks, so no data is lost. BUT then i can't access it regular? This data has to be accessed on a regular basis.

9
  • Show output for SELECT COUNT(*), MAX(LENGTH(LogTextData)) FROM tablename;. What operations are performed on this data - retrieve only, search, FTS, etc.?
    – Akina
    Commented Aug 31, 2021 at 11:53
  • 1
    Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer.
    – Community Bot
    Commented Aug 31, 2021 at 12:06
  • @Akina when I run it I get: Error Code: 2013. Lost connection to MySQL server during query
    – Mads
    Commented Aug 31, 2021 at 12:56
  • Do you need the details of LogTextData freshly dumped and moved to the playground? Or would stale data be OK?
    – Rick James
    Commented Aug 31, 2021 at 17:39
  • @RickJames I don't know what stale data is, but as long at the LogTextData can be printed on a html page, and there isn't any invalid data in the text, then it's okay.
    – Mads
    Commented Sep 1, 2021 at 6:06

1 Answer 1

1

Keeping big files on disk and just link to them from the database is a valid approach used by many software solutions.

However, 3.1G isn't terrible. So, assuming you want to keep your data in the database:

You may want to consider using mariabackup instead of mysqldump as that is faster, especially when your data grows to the gigabyte range. Note however that mariabackup is a physical backup tool, as opposed to mysqldump, which performs logical backups. So although the backups are faster, they are not as portable. If you must have logical backups only, then mydumper might be an option which can be faster than mysqldump.

Another thing to consider is column compression. MariaDB 10.3 introduced the Storage-Engine Independent Column Compression feature. Assuming this is suitable to your use-case, you can simply do something like:

ALTER TABLE `Log` 
  MODIFY LogTextData LONGTEXT COMPRESSED;

The column is compressed on disk, but is automatically decompressed when you access it through SQL queries.

See also Wagner Bianchi's blog article on this topic where he compresses a 11M table to 4M using this approach: Wagner Bianchi: The MariaDB Storage-Engine Independent Column Compression

5
  • Thanks, this was very informative to me.
    – Mads
    Commented Sep 1, 2021 at 13:16
  • Do you know if there is a COMPRESSED methode for MariaDB 10.1.25
    – Mads
    Commented Sep 1, 2021 at 13:21
  • @Mads No, the COMPRESSED feature described above is only available in MariaDB 10.3 and later. (Note that MariaDB 10.1 was EOL in Oct. 2020.) Upgrading usually isn't very hard, though. Is that an option? If not, you could also let your application/Python do the compression & decompression, although not sure how efficient that would be. There is also InnoDB page compression, but it seems a bit complicated and I've never used it.
    – dbdemon
    Commented Sep 1, 2021 at 13:40
  • I'm not a fan of table compression of MySQL. MariaDB's column compression makes the most sense for this app.
    – Rick James
    Commented Sep 1, 2021 at 16:54
  • 11M:4M is about 3:1, which is very typical for "text" compression everywhere.
    – Rick James
    Commented Sep 1, 2021 at 16:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.