tag:blogger.com,1999:blog-50891201578640484712012-01-11T21:53:22.318-02:00Igor Ribeiro Sucupirahttp://www.blogger.com/profile/12589406275720759327noreply@blogger.comBlogger61100tag:blogger.com,1999:blog-5089120157864048471.post-31236680935685423892011-05-21T19:04:00.003-03:002011-05-22T21:49:58.962-03:00

Oh, yes: I have decided to take part in that holy war, instead of humbly writing another post about Mnesia (which may come some day...). First of all, let's make clear that I am a software developer (currently in a technical lead position, but still a developer), so that you can read this post with all of your prejudices on. Like most people, I believe that, in general, developers should only

Igor Ribeiro Sucupirahttp://www.blogger.com/profile/12589406275720759327noreply@blogger.com0tag:blogger.com,1999:blog-5089120157864048471.post-30813417358085617422010-05-23T00:16:00.006-03:002010-05-23T00:31:59.573-03:00

This is the third part of my series of posts about Mnesia. From this third post on, I'll probably start to include some information that you can find elsewhere without too much trouble. After all, it's good to have them arranged together. I'm also talking about stuff that might be a little bit obvious for some people, like this next one... Automate table management As you certainly know, once

Igor Ribeiro Sucupirahttp://www.blogger.com/profile/12589406275720759327noreply@blogger.com4tag:blogger.com,1999:blog-5089120157864048471.post-39579699309341578112010-05-21T04:51:00.008-03:002010-09-04T14:28:25.197-03:00

This is my second post about the not-so-well-known relevant facts I have learned by working on a project based on Mnesia. Check my last post before reading this one. Let's go... Do not use mnesia_frag to list records Suppose your foo table, properly fragmented and distributed across dozens of servers, contains a secondary index on its second field. I guess you will eventually want to list all

Igor Ribeiro Sucupirahttp://www.blogger.com/profile/12589406275720759327noreply@blogger.com0tag:blogger.com,1999:blog-5089120157864048471.post-16600563221560041842010-05-20T06:24:00.001-03:002010-05-22T18:50:19.659-03:00

I've been working for a little more than a year now on a private back end project at my company, making heavy use of Erlang and Mnesia to build a distributed system that stores high volumes of data. With the system in production for some months and working really fine since its first deployment, I decided it was a good moment to try to remember the most important lessons I have learned about

Igor Ribeiro Sucupirahttp://www.blogger.com/profile/12589406275720759327noreply@blogger.com6tag:blogger.com,1999:blog-5089120157864048471.post-22267917534660958192009-11-19T12:31:00.005-02:002009-11-20T02:58:57.140-02:00

Using the consistent hashing scheme I described in my last post, I have created a table with 400 fragments and done a bunch of writes to it. Although data distribution was very good in this test, the performance was really crappy, so I supposed Mnesia was doing some copying around of the hash_state (which contains the tree I use for consistent hashing). As Ulf Wiger commented here, Mnesia is

Igor Ribeiro Sucupirahttp://www.blogger.com/profile/12589406275720759327noreply@blogger.com0tag:blogger.com,1999:blog-5089120157864048471.post-26483794604487084752009-11-16T13:30:00.004-02:002009-11-16T20:51:07.673-02:00

If you work with Mnesia and use the mnesia_frag module for partitioning tables, maybe you know that Mnesia's default hashing module deals very well with the situation in which you need to add one more fragment to your table. Actually, the rehashing scheme has two important properties: No data will need to be moved to any fragment that is not the new one. Only the keys in one of the old fragments

Igor Ribeiro Sucupirahttp://www.blogger.com/profile/12589406275720759327noreply@blogger.com5