-
-
Scout Monitoring
Rennaisance engineers rejoice! 1 gem 5 min to app monitoring. 5-minute onboarding. No sales team. Devs in the support channels. No DevOps team required. Get the free app insights every engineer deserves with Scout Monitoring.
The primary culprits were two tables (and their huge indexes) that contributed approximately 90% to the total size of the database. One of them was an audit trail (paper trail versions, to be exact), and the second one was more domain-specific for short-term rentals. It's a pre-computed cache of prices for properties depending on various conditions so that they don't need to be computed each time on the fly and can be easily distributed to other services.
At that point, we had to figure out some custom solution, as we didn't want to change the migration strategy from just the full load to the combination of full load and CDC. The good news was that we had already been using something that could be very useful in designing a custom solution - performing a bulk insert (using activerecord-import) of the archived records. It proved to be fast enough to restore a significant number of records. Also, nothing was preventing us from having a way higher parallelization degree than DMS. This could be our solution.
Related posts
-
historical data and "point in time" data modeling techniques, advice.
-
Best rails tools to automatically handle logging of things like all a user's actions, or changes to a record in a module - primarily for audit purposes.
-
Best rails tools to automatically handle logging of things like all a user's actions, or changes to a record in a module - primarily for audit purposes.
-
Inventory/Sales Management module built on a Rails app - what would be the best way to "version" updates made against an SKU.
-
is there a gem for tracking adhoc rails console changes