It’s autumn and November is right around the corner! We all know what this means…
Blogging is without a doubt the most important way to get your ideas out to the world, whether your personal take on a recently released album or your professional word on the latest updates to various products from your organization. While social media pushes our concepts out in small bursts, a blog is more of a time tested method for putting our thoughts on record for our users, our readers, and our customers to understand. A blog is still the non-ephemeral placeholder of concepts, and therefore remains a necessary for the modern company.
From time to time our data team gets requests for advice on how to perform cleanup operations against large database tables. Typically, these originate in a ticket requesting information about how the disk is being used or why a specific table is performing poorly.
Somewhat less often, we are asked us to explain why a cleanup attempt has failed or why it has caused downtime for an application. Managing these types of operations with minimal or no downtime can be a challenge given the way a database like MySQL performs these tasks.
The most common form of table cleanup operation we are asked about is for the sessions table. Even though these are not really recommended practice(https://guides.rubyonrails.org/action_controller_overview.html#session) they are still quite common to see. Depending on your application workload and use cases these tables can grow very quickly in size; often including older records that are never going to be used again. Even though the data payload in each row is relatively small, it's not uncommon to find sessions tables that are 10 or 20 GB in size—often larger than the rest of the database combined.
While there is no automatic session cleanup built into a rails app it happens to be really easy to write a rake task that handles this cleanup for you. In fact, it's so easy that it's often overlooked until the table has reached the size where it is difficult to manage
Technology changes almost as frequently as the latest fashion trend. What’s in vogue today will be out of favor tomorrow; some technologies will fade away while others morph into something new. One of the technologies currently going through a transformation is Platform-as-a-Service (PaaS). Changes in business requirements, government regulations, and developer strategies are placing new demands on PaaS providers, and a new type of PaaS infrastructure is starting to emerge to meet the changing requirements.
There’s more than one way to build a web application. No matter what type of application you are trying to create, your programmers have their preferred approach and their preferred code languages to accomplish the task. In the world of web applications, most program developers have to decide between Ruby on Rails versus PHP.
Cloud computing has made hosting business-critical applications easier and less expensive. Application hosting makes deploying the resources you need easier and faster—without the overhead of additional hardware, software, and personnel. Once you decide to host your business applications, the question becomes, what criteria do you need to consider when looking for an application hosting provider?
Ruby on Rails continues to gain popularity as an effective platform for developing web and cloud applications. Today, there are at least 865,472 business websites running on Ruby on Rails, and the number is growing. Ruby on Rails continues to gain momentum partly because it is open source, which means the developer community continues to improve the platform, and also because Ruby on Rails was created to promote “programmer happiness,” which means programmers are more productive and more efficient developing in Ruby on Rails than on other platforms such as .NET and Java.