If you're in the Los Angeles area on Feb 15, come hear my talk at LAMySQL inspired by learnings from real-life experiences. In addition to hearing a very unique and interesting talk, you can win an AppleTV thanks to awesome folks at @NoodleYard.
Real-Life Use Cases From Data Administration Hell
Data is the most valuable asset of an organization because it's irreplaceable.
Yet, we hear about f**k ups related to data administration every day by startups and organizations of all sizes. Sometimes it's no one's fault. Sometimes it's the fault of a drunk friend who shouldn't have been [wherever he was] at the first place.
Yet, at other times, the disaster could have been prevented. Sometimes, these f**k ups are caused by bad design. Sometimes, it's a bad query that made it into the production branch. Sometimes, it's a human error that ruins the day.
Ever had a bad query slip through QA? Or a configuration option that you thought would help the situation? Sometimes, the resulting disaster could have been prevented if those operating had simply followed the rules. Sometimes it's the lack of presence of rules that leads to a disaster. Sometimes, the "acts of prevention" worsen the impact of the disaster. Sometimes it's over confidence of those administering data.
Imagine deletion of a wrong record or from a wrong server. Or not treating the only SAN as a SPOF. Sometimes, the f**k up has been happening for years, yet no one realized or fixed it.
Sometimes, the f**k up is created intentionally. By focusing on things other than operational and capacity requirements. Sometimes, a small error threatens the very existence of a company.
At least once of a $100M company.
These f**k ups happen everywhere. At organizations of all sizes.
In this talk, Frank Mashraqi will explore real-life inspired, breath-taking (anonymized) use cases that created data administration hell for an organization. He will also explore how, if at all, these f**k ups could have been avoided.
This session presents an opportunity to learn from the real-life costly data administration mistakes of others and what strategies can help you with not getting caught off guard.
Bio
With more than a decade of scalability, disaster recovery and engineering management experience under his belt, Frank specializes in building and scaling NoSQL and SQL based platforms for graph processing and big data deployments using low concurrencies.
He is an expert in audience acquisition through organic search engine optimization and audience monetization through cutting edge technologies as re-targeting, social targeting and influencer targeting.
His past experience includes co-founding a graph processing company that applies advanced sociological theories to online advertising, scaling Fotolog to help it become the 13th most visited site on the Internet, and advising companies like Betaworks, Bitly, TwitterFeed, Chartbeat and ShermansTravel.
He holds a BBA in Accounting and a BS in Computer Information Systems.
PS: Many thanks to JoeDevon for inviting me to speak
PS: I'll be driving from the Bay Area so if anyone is interested in riding with me from SF to LA and back, let me know :)
Specializing in big data deployments using MySQL / NoSQL Solutions. Topics: [mysql tutorial] [database design] [mysql data types] [mysql commands] [mysql dump] [database development] [mysql training] [mysql scalability] [mysql sharding] [mysql performance tuning]
Showing posts with label bigdata. Show all posts
Showing posts with label bigdata. Show all posts
Monday, February 07, 2011
Wednesday, December 01, 2010
Big Data: Freedom or Something Else?
Googling around, I came across Bradford Cross' article, Big Data Is Less About Size, And More About Freedom. Bradford writes, " The scale of data and computations is an important issue, but the data age is less about the raw size of your data, and more about the cool stuff you can do with it."
Even though the article makes some good points, I'm not sure I can agree with Bradford's point of view here. As an architect, when I think in terms of Big Data, the ability to do "cool stuff" is probably the last thing that crosses my mind. Big Data, to me, is about ensuring constant response time as the data grows in size without sacrificing functionality.
What do you think Big Data is about? Is it merely about being able to do 'cool stuff' with your data? Is it about ensuring constant access/response times? Or is it about something else? I'm eager to hear your thoughts.
Even though the article makes some good points, I'm not sure I can agree with Bradford's point of view here. As an architect, when I think in terms of Big Data, the ability to do "cool stuff" is probably the last thing that crosses my mind. Big Data, to me, is about ensuring constant response time as the data grows in size without sacrificing functionality.
What do you think Big Data is about? Is it merely about being able to do 'cool stuff' with your data? Is it about ensuring constant access/response times? Or is it about something else? I'm eager to hear your thoughts.
Subscribe to:
Posts (Atom)