The third meeting for the MySQL User Group NL will be hosted by
Snow B.V. in the
Snow
office in Geldermalsen.
The Agenda:
Please RSVP on the meetup.com page.
The user group now has more than 100 members!
One of the main responsibilities of any database administrator is to keep a close eye on how database performance is impacting size and storage. Decisions will have to be made on whether or not to make changes within the database structure or application itself, or to make the changes on the storage and resource side [...] Read More
On February 28 at 1pm EST I’ll be taking part in a webinar, sponsored by ScaleBase, on strategies for scaling MySQL.
Scalability is one of the primary drivers we’ve seen for database users considering alternatives to traditional relational databases. That could mean adopting an entirely new database for new projects or – more likely for existing applications – looking at various strategies for improving the scalability of an existing database.
During the webinar I will be joined by Doron Levari and Paul Campaniello, both from ScaleBase, which enables applications to scale without disruption to the existing infrastructure. We’ll be discussing, amongst other things:
TempoDB’s timely DBaaS for the Internet of Things. ScaleBase 2.0. And more
For 451 Research clients: TempoDB has timely database service for the Internet of Things bit.ly/YcQuqA
— Matt Aslett (@maslett) February 13, 2013
For 451 Research clients: ScaleBase provides centralized management of distributed MySQL databases bit.ly/YcQTcs
— Matt Aslett (@maslett) February 13, 2013
For 451 Research clients: XtremeData turns its attention to cloud-based data warehousing bit.ly/XB7MLY
— Matt Aslett (@maslett) …
[Read more]
I just came across this: "Scaling Pinterest and adventures in
database sharding" (http://gigaom.com/data/scaling-pinterest-and-adventures-in-database-sharding/)
"Pinterest has learned about scaling the way most popular sites
do — the architecture works until one day it doesn’t"Pinterest
found out that "the architecture" is not scalable and they turned
to development of a Scale Out mechanism also called
Sharding.
I find it amazing that sharding, or in other words, the idea of
"scale out by splitting and parallelizing data across
shared-nothing commodity-hardware" is not supplied "out of the
box" by "the architecture" (such as database, load-balancer, any
other IT stuff). I'm wondering who was the one that
decided that an IT issue like scale-out should
be outsourced from the database to the …
Next gen app providers (and perhaps more specifically, database architects) are clamoring for database technologies that just work. At least, that’s the message we got from one of our newest customers: Mozilla. Earlier this month, we caught up with Sheeri Cabral, database architect at Mozilla and and overall MySQL rock star, to get the down-and-dirty on why [...] Read More
On the 8/16 I conducted a webinar titled: "Scale Up vs. Scale
Out" (http://www.slideshare.net/ScaleBase/scalebase-webinar-816-scaleup-vs-scaleout):
ScaleBase Webinar 8.16: ScaleUp vs.
ScaleOut from ScaleBase
The webinar was successful, we had many attendees and
great participation in questions and
answers throughout the session and in the
end. Only after the webinar it only occurred to me
that one specific graphic was missing from the webinar deck. It
was occurred to me after answering
several audience questions about "the difference
between …
Yesterday (4/19) I attended the AWS Summit in NYC (http://aws.amazon.com/aws-summit-2012/nyc).
I'm a big fan and also a heavy user of AWS especially S3, EC2,
and naturally, RDS. In every point in time I have several dozens
of AWS machines running for me out there in the East region, and
in some cases when we do some special benchmarks and tests,
number of EC2 and RDS machines can easily reach 3-digit. As I
said, I'm a fan...
A few quotes I was able to catch and document on my laptop, on my
laps...:
"When you develop an app for facebook, you must be prepared (and
be afraid) that to your party, not noone will show up, but
everybody will show up!" So true! Simple and true. We all want to
succeed, to have success with our app. We have to think about
scaling from day 1.
"Database was bottleneck for building of sophisticated apps. This
is …
There are ways to scale databases, unfortunately some are
limited, some introduce complexities, some are do not fit the
cloud...
By scaling solution I mean a solutions that help me scale my
existing environment, my existing RDBMS. Some magic or technology
that will take my existing Oracle or MySQL for example, to the
next level, without porting to a new DB engine/vendor and without
completely recoding my app.
Let's try to organize things a bit in this very summarized table,
just to get the hunch of it. I can't imagine to cover it all in 1
table or even 100 pages, but that should be a start of a
meaningful discussion to continue in next posts:
| Solution | Scales reads? | Scales writes? | Scales data? | Scales sessions? | … |
In my heart, I'm a DBA, always was and always will be. People say
I'm a database guy by the way I think, keep my car, and file my
music and also bank statements... However I did great deal of
development, design, architecture on the apps side. I (hope to)
have some perspective.
Applications come and go. The second programming language I've
ever learned and worked on was COBOL, some still say most of
the world's lines of code are written in this language, maybe so,
but anyway I since then have known and written in dozens of
programming languages, from Assembly to Force.com, from Pascal to
Delphi, from functional C to Object
Oriented SmallTalk, C++, Java and , from compiled C/CGI
to interpreted Perl, ASP and Ruby back to compiled node.js... My
first applications ran on Main-Frame with green screen, later I
created beautiful graphic client-server applications, later I had
to create hideous white web applications …