Once the new table was created in Vitess, it was time to fill it with data. Slack uses Vitess to ensure we can provide reliable access to our database as we continue scaling (check out a talk about using Vitess at Slack from one of our senior staff engineers, Mike Demmer, who also helped me by creating the new table in Vitess!). Vitess is a tool that helps reduces the load on MySQL databases by creating multiple databases and routing each request to a specific database, like a hash table. ![]() Once the table’s schema was chosen, it had to be created in our Vitess cluster. | workspace_id | pref_name | pref_value | It also lets us add new preferences without needing to change the structure of the table. Each pref is stored as a new row in the table, meaning we don’t get any extra information when fetching only one pref. The table has three columns: the workspace ID, the name of the preference, and a JSON blob of the value for that preference. To split up workspace preferences and give us flexibility to add new preferences in the future, I chose to use an Entity/Attribute/Value (EAV) table. But as we continue to add more customization for workspaces, this would mean adding new columns to the table - an expensive procedure. ![]() Another strategy would be to create a database table with a column for each preference, so each workspace would have a single row in the table. We could store a workspace ID with a JSON blob of all of those workspace’s preferences (but as previously discussed, lumping all preferences together made us retrieve a lot of unnecessary information when accessing a single preference). There are many possible data models for storing workspace prefs.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |