"With data, it is almost always easier and cheaper to start clean and import
into the new database that to try to fix a badly designed schema and poorly
written data retrieval code."
You know what they say: "There's never time to do it right, but always time
to do it over."
Sounds like a classi
With data, it is almost always easier and cheaper to start clean and
import into the new database that to try to fix a badly designed
schema and poorly written data retrieval code. Especially true with
all the really good new tools for cleaning and importing data.
Facebook's only issue with movin
With the capital facebook has, I'd say build the perfect system from scratch
and then import the existing data. Certainly not feasible for many
businesses, but finances shouldn't be a problem for facebook
J
-
Ninety percent of politicians give the other ten percent a bad reputation. -
Henry Ki
On Sun, Jul 10, 2011 at 1:01 AM, Robert Munn wrote:
> Makes no sense to port to a new db unless it is one specifically
> designed for the kind of scale they expect to see well into the
> future.
I find this sort of problem to be very interesting to solve. Not that I
could completely comprehen
:-)
On Sat, Jul 9, 2011 at 11:56 PM, Maureen wrote:
>
> Yeah, I'm sure that has a lot to do with it. Wish they'd hire me to fix it.
>
> On Sat, Jul 9, 2011 at 11:48 PM, Robert Munn wrote:
>>
>> I wonder how much of that has to do with the added complexity of the
>> caching layer and all the ot
Yeah, I'm sure that has a lot to do with it. Wish they'd hire me to fix it.
On Sat, Jul 9, 2011 at 11:48 PM, Robert Munn wrote:
>
> I wonder how much of that has to do with the added complexity of the
> caching layer and all the other moving parts in their current
> solution.
>
> On Sat, Jul 9,
I wonder how much of that has to do with the added complexity of the
caching layer and all the other moving parts in their current
solution.
On Sat, Jul 9, 2011 at 10:18 PM, Maureen wrote:
>
> Even so, the data structure would not that complex. I'm be more
> inclined to think most of the speed
Even so, the data structure would not that complex. I'm be more
inclined to think most of the speed problems with Facebook site are
function of poor design rather than tool set. They apparently cannot
even write a simply select to show news feed posts in chronological
order across timezones.
On
Makes no sense to port to a new db unless it is one specifically
designed for the kind of scale they expect to see well into the
future.
On Sat, Jul 9, 2011 at 6:25 PM, Maureen wrote:
>
> Facebook's data structure would be a breeze to rewrite in any database
> format. Simple stuff. Posts in a
"That is very a interesting read. Very."
One thing the article does not make clear: There are a lot of companies
that would love to have the problems Facebook has, at least in regards to
maintaining data.
J
-
Ninety percent of politicians give the other ten percent a bad reputation. -
Henry
Facebook's data structure would be a breeze to rewrite in any database
format. Simple stuff. Posts in a few different flavors, Walls in a
few different styles, and membership tracking. If their presentation
layer is isolated from the data layer, the whole project would be
piece of cake.
On Fri
So I go to read more and that's the end of the article.
Now I have to search to find out the what and how.
.
On Fri, Jul 8, 2011 at 8:39 AM, Jerry Barnes wrote:
>
>
> Read more here:
> http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-than-death/
>
~
That is very a interesting read. Very.
-Cameron
On Fri, Jul 8, 2011 at 8:39 AM, Jerry Barnes wrote:
>
> Facebook trapped in MySQL fate worse than death
>
> Excerpts:
>
> According to database pioneer Michael Stonebraker, Facebook is operating a
> huge, complex MySQL implementation equivalent
13 matches
Mail list logo
