On Sunday, October 12, 2014 9:51:55 AM UTC+1, Yongbiao Long wrote:
> Hi, everyone,
> 
> 
> I've learned Rails(Web development) on my own for two months, and came to a 
> situation like this:
> 
> 
> There are two tables A and B in my database. A 'has_many` B. For every user 
> input, There is an entry in table A. At the same time, I need to add a huge 
> number(say 100,000) of entries in B. As table A grows, table B seems to grow 
> uncontrollably. There must be performance issues in later data manipulation 
> operations, or even 'overflow` problems. I use Mysql.
> 
> 
> My initial thought was to split table B, for example, for every entry in 
> table A, create a new table (on the fly) for it. The questions are:
> 
> 
> Is my thought right? 
> If yes, then how to design the models and migrations to represent the 
> relationship correctly?
> If not, what are good practices to solve this kind of problem?
> 
> 


I've had hundreds of millions of rows in one table without problems before. The 
important think is not just the number of rows but your access patterns. For 
example I currently do something vaguely similar with some mongo data: we 
create one collection per day (and drop the collection from a few days ago) 
because dropping a collection is very fast compared to deleting several 
millions documents from a larger collection.

Another real world example of this is new relic: at least at one point they 
created one table per customer per hour ( 
http://highscalability.com/blog/2011/7/18/new-relic-architecture-collecting-20-billion-metrics-a-day.html).
 There's is a somewhat specialised case: high insert performance and 
specialised read/aggregate and delete patterns pushed them that way. 

This is an uncommon pattern. While it allows a form of sharding and avoids the 
need for blocking migrations on very large tables it will make everyday life 
more complicated. As far as I'm aware you'll be pretty much on your own if you 
go down the path. 

Odds are you don't need this. If you do, think really carefully about your 
access patterns first

Fred

> 
> I'd be very grateful if you could only give some hints, doc or good articles 
> about it.
> 
> -- 
> Best Regards

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-talk+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rubyonrails-talk/506e2d38-5ad1-408f-85cc-6da265ff9913%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to