On Sun, Nov 30, 2008 at 6:07 PM, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:

>
>
> Hi ... new to Scala and Lift.  I'm having trouble understanding how to
> think about a project with a horizontally scaled database.  I guess
> people call this "sharding" these days?  My existing app uses PHP, no
> framework, and no O-R mapping.  It's all PHP/MySQL with SQL
> statements.  Some O-R mappers seem to partially support sharding and
> I'm wondering if Lift's does?  Adding AJAX to this app is not going to
> be easy, and I'm considering a rewrite now that I know a little more
> about what I'm doing.  Plus, I'm kind of bored with PHP.  When it
> comes to database access, does Lift avoid the scalability problems I
> hear Rails has?


Lift has built in DB sharding.  You can have multiple RDBMS connection
identifiers.  Each record has its connection identifier associated with it
(where it came from) and there's a place in each MetaModel to insert a
function to calculate the connection identifier given a record to be saved
or a primary key to be recalled.

With that being said, Rails' scaling issues have some to do with assuming
infinite RDBMS capacity or that memcached will solve all woes.  Rails also
scales badly because the MRI (Matz Ruby Implementation) sucks badly and a
fair number of MRI instances fail or snarf all available system resources.


>
>
> Or, is there a better way do horizontally scale these days?  I see
> that SQL Server supports distributed partition views, which I'm still
> learning about.  Something at the database server side of things which
> transparently handles the horizontal scale-out would be great.  Not
> sure if distributed partition views actually do this though.


I'm a very big fan of using Actors as a smart caching mechanism.  With the
Skittr example, I scaled a Twitter-like service to 1M users on a dual
process box.  With all of your questions and updates going through Actors,
you've got a lot of fine-grains control over caching policies, etc.

But we're also talking about scaling to Twitter/Facebook type traffic.  For
the normal 100K users, 1K active users kinda sites, you don't have to worry
much.


>
>
> This also looks like it'd make my life easier:
>
> http://www.hivedb.org/
>

Gaaak.  If you're hell-bent on staying with SQL, I'd strongly suggest using
something built on top of PostgreSQL.


>
> thanks,
>
> Bob
>
>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to