tag:blogger.com,1999:blog-31421954.post116310100782437231..comments2023-10-30T08:23:12.960-07:00Comments on mySQL DBA, Architecture, Dev, Scale, HA, Code : Unorthodox approach to database design Part 2:FriendsterDathan Pattishallhttp://www.blogger.com/profile/00356367514107959723noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-31421954.post-50733236244005419462008-12-01T02:51:00.000-08:002008-12-01T02:51:00.000-08:00Web Art Sense a web design company is here for a p...Web Art Sense a <A HREF="http://www.webartsense.com" REL="nofollow">web design company</A> is here for a purpose to make art and design of your imagination alive and real on the web platform. After several months of hunting of the best talent and struggling for the name of their design company they finally reached a vertical which engages their vision of togetherness. The best talented people in web designs have joined hands to compete and provide innovative, unique concepts to users/clients all across the globe. Web Art Sense is not any design company; they take real care of having your brands be presented that invokes your revelation to others who see it.<BR/><BR/><B>Web Art Sense</B> has their sales offices in London, New Jersey and New Delhi are heading towards marketing themselves to main continents of Europe, Australia and America. Web art sense already has ground foundation and is providing web based design development and SEO Services in countries like USA, UK, Australia and Italy. <B>Web Art Sense</B> has been growing above hundred percent every financial year since its foundation.<BR/><A HREF="http://www.webartsense.com" REL="nofollow">Web Design Company</A><BR/><BR/><BR/>Web Art Sense a leading <A HREF="http://www.webartsense.com" REL="nofollow">web design company</A>, affordable web design, web development, ecommerce, XHTML services. <A HREF="http://www.webartsense.com" REL="nofollow">Web Design Company</A> offers a complete collection of web design solutions for business. Web Art Sense team of professionals with proven knowledge in the field of web design & development are skilled of providing high quality, e commerce websites, development and website redesign & maintenance solutions.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-31421954.post-90230925016179032782008-06-24T12:48:00.000-07:002008-06-24T12:48:00.000-07:00Still no response for the issue that requires quer...Still no response for the issue that requires queries across multiple shards?<BR/><BR/>BTW, nice article, but your failure to utilize commas correctly forced me to read many sentences more than once to infer proper meaning. I suggest either getting an editor or reading this book:<BR/><BR/>http://www.amazon.com/Eats-Shoots-Leaves-Tolerance-Punctuation/dp/1592400876Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-31421954.post-86782366514587857702008-06-16T12:54:00.000-07:002008-06-16T12:54:00.000-07:00Interesting post the biggest problem with LJ is th...Interesting post the biggest problem with LJ is the friend page isnt it?<BR/><BR/><BR/>---------------------------<BR/><A HREF="http://www.greenlightinteriors.co.uk" REL="nofollow">Interior Designs Scotland<BR/></A>Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-31421954.post-236271329276863962007-08-23T22:21:00.000-07:002007-08-23T22:21:00.000-07:00RE:"Splitting by one table (users in this case) is...RE:"Splitting by one table (users in this case) is obvious. But what about sharding on more than one axis? Suppose I have another huge table that I want to split, and it has to join with the users table."<BR/><BR/>What you are speaking to isn't necessarily a shard, but where you will get some real performance increase is when you split a table with many columns into two: one with the data that you query often, and the other with data that you don't. This will reduce the overall row size, thus faster to scan, sort, join or whatever. Along with selectively de-normalizing your data, this can make a big difference.Unknownhttps://www.blogger.com/profile/16051295755054909699noreply@blogger.comtag:blogger.com,1999:blog-31421954.post-23841104199635059842007-08-16T17:24:00.000-07:002007-08-16T17:24:00.000-07:00"Splitting by one table (users in this case) is ob..."Splitting by one table (users in this case) is obvious. But what about sharding on more than one axis? Suppose I have another huge table that I want to split, and it has to join with the users table."<BR/><BR/>My guess is that this is why denormalization is mentioned prominently as one of the features of sharding -- you'd be merging those giant tables into one ginormous table, and then sharding it. You would have some considerable data redundancy in such a system, and you'd probably have to move relationship checking to code, not relations.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-31421954.post-58570506156089775672007-03-07T07:25:00.000-08:002007-03-07T07:25:00.000-08:00Very interesting post, I have to admit I am a litt...Very interesting post, I have to admit I am a little confused as to how you create data for a whole bunch of different users though. Like on a users friends page.jacksonhhttps://www.blogger.com/profile/06579239848879006903noreply@blogger.comtag:blogger.com,1999:blog-31421954.post-1167293627686773792006-12-28T00:13:00.000-08:002006-12-28T00:13:00.000-08:00Hmm... Quite an interesting read.Hmm... Quite an interesting read.Legit Freebies Guyhttps://www.blogger.com/profile/00326581293343328574noreply@blogger.comtag:blogger.com,1999:blog-31421954.post-1165989288180403402006-12-12T21:54:00.000-08:002006-12-12T21:54:00.000-08:00very interesting, but one question.suppose now I h...very interesting, but one question.<BR/>suppose now I have 10 mysql backends, i split my users to them. one year later, we should add 10 more backends, how could I split the old data on the previous 10 backends to the new 20 backends?<BR/><BR/>LouisAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-31421954.post-1164755374818950292006-11-28T15:09:00.000-08:002006-11-28T15:09:00.000-08:00Interesting read.I've done some sharding of data a...Interesting read.<BR/><BR/>I've done some sharding of data across machines, but it was in a search engine and the storage engine was designed from scratch around it, so it was pretty easy to implement. And it could scale on cheap machines with small disks to huge capacities. This is maybe the best way to scale with cost in mind.<BR/><BR/>I'm now thinking of splitting MySQL data across machines for another project, and one question comes to mind:<BR/><BR/>Splitting by one table (users in this case) is obvious. But what about sharding on more than one axis? Suppose I have another huge table that I want to split, and it has to join with the users table. Off the top of my head, this sounds like it would make queries much much more complicated and make a whole mess out of the design. But I haven't really given it much thought yet.<BR/><BR/>Have you done anything like that? What ae your thoughts?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-31421954.post-1163702983419086902006-11-16T10:49:00.000-08:002006-11-16T10:49:00.000-08:00@ chris:What happens when your data consumes 800 G...@ chris:<BR/><BR/>What happens when your data consumes 800 GB of space?<BR/><BR/>Would you replicate your data to many slaves?<BR/><BR/>1TB slaves costs a lot of money and at best you can get maybe 1% of the data in memory.<BR/><BR/>If the application hardly writes, will always stay small then replication is good enough.Dathan Pattishallhttps://www.blogger.com/profile/00356367514107959723noreply@blogger.comtag:blogger.com,1999:blog-31421954.post-1163701691220418732006-11-16T10:28:00.000-08:002006-11-16T10:28:00.000-08:00For our solution it made much more sense to use re...For our solution it made much more sense to use replication. Over 80% of our queries where READs we wrote our statistics (page views, etc) to a totally different machine. So replicating data that isn't updated often is a solid solution. <BR/><BR/>Chris - my two centsAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-31421954.post-1163442671286874792006-11-13T10:31:00.000-08:002006-11-13T10:31:00.000-08:00LJ split their of data by user so that my user liv...LJ split their of data by user so that my user lives on a different partition than yours, but this scheme has partitioned it by type. Therefore, all users are in one scheme, messages, photos, testimonials in another. <BR/><BR/>Thus bringing data together isn't a problem unless you're displaying different types of data, in which case I think it's relatively cheap to issue the appropriate query for each type & then sort them all together on the application side.veganloveburgerhttps://www.blogger.com/profile/11935117470776753328noreply@blogger.comtag:blogger.com,1999:blog-31421954.post-1163113808151742812006-11-09T15:10:00.000-08:002006-11-09T15:10:00.000-08:00Interesting.I understand Livejournal split their u...Interesting.<BR/><BR/>I understand Livejournal split their users into different clusters of machines and that the biggest problem with this is bringing data together from the separate machines for the "friends" page (which contains entries from several users).<BR/><BR/>How does your design cope with queries that need info from more than one shard?<BR/><BR/>TomAnonymousnoreply@blogger.com