<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Database on Bulrush Labs — Richard Tibbetts</title><link>https://bulrushlabs.com/articles/tag/database/</link><description>Recent content in Database on Bulrush Labs — Richard Tibbetts</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 11 Apr 2008 22:34:00 +0000</lastBuildDate><atom:link href="https://bulrushlabs.com/articles/tag/database/index.xml" rel="self" type="application/rss+xml"/><item><title>When neither a column store nor a row store is the answer</title><link>https://bulrushlabs.com/articles/2008/04/11/when-neither-a-column-store-nor-a-row-store-is-the-answer/</link><pubDate>Fri, 11 Apr 2008 22:34:00 +0000</pubDate><guid>https://bulrushlabs.com/articles/2008/04/11/when-neither-a-column-store-nor-a-row-store-is-the-answer/</guid><description>&lt;p&gt;A few days ago I found myself giving database advice to a friend with a new startup. His problem is a pretty common one: he has a very large corpus of data, over which he will run compute-intensive proprietary algorithms. Both the data and the computation will require a cluster of machines. He has a prototype based on Postgres. His question to me: should I continue to use a row store (Postgres) or should I use new technology, specifically a column store?&lt;/p&gt;</description></item><item><title>Google commences another assault on the traditional database community</title><link>https://bulrushlabs.com/articles/2008/04/08/google-commences-another-assault-on-the-traditional-database-community/</link><pubDate>Tue, 08 Apr 2008 09:32:00 +0000</pubDate><guid>https://bulrushlabs.com/articles/2008/04/08/google-commences-another-assault-on-the-traditional-database-community/</guid><description>&lt;p&gt;Many in the blogosphere noticed when &lt;a href="http://www.databasecolumn.com/"&gt;Stonebraker and Dewitt at The Database Column&lt;/a&gt; took offense at the idea that &lt;a href="http://www.databasecolumn.com/2008/01/mapreduce-a-major-step-back.html"&gt;map-reduce is the solution to many of life’s problems&lt;/a&gt;. The idea that a simple idea, promoted by a services company, can blow away 20+ years of distributed database research, bothers them for some reason. Sure, it may not be the best solution to every problem, but it is a sufficient solution to many problems.&lt;/p&gt;</description></item><item><title>OOPSLA 2007: “The Popularity Cycle of Graphical Tools, UML, and Libraries of Associations” – not the workshop I expected</title><link>https://bulrushlabs.com/articles/2007/10/23/oopsla-2007-the-popularity-cycle-of-graphical-tools-uml-and-libraries-of-associations-not-the-workshop-i-expected/</link><pubDate>Tue, 23 Oct 2007 09:59:00 +0000</pubDate><guid>https://bulrushlabs.com/articles/2007/10/23/oopsla-2007-the-popularity-cycle-of-graphical-tools-uml-and-libraries-of-associations-not-the-workshop-i-expected/</guid><description>&lt;p&gt;Today was my first day at &lt;a href="http://www.oopsla.org/oopsla2007/index.php?page=home/"&gt;OOPSLA 2007&lt;/a&gt; in Montreal. After a brief exposure to the amazing “Underground City” (really a shopping mall that is infecting downtown like a cancer), I crashed a workshop for which I had not signed up, and had a completely different experience than I had planned at &lt;a href="http://www.codefarms.com/OOPSLA07/workshop/index.htm"&gt;The Popularity Cycle of Graphical Tools, UML, and Libraries of Associations&lt;/a&gt;.&lt;/p&gt;&#10;&lt;p&gt;The title implied it was the workshop about graphical programming languages and tools. As an author of a graphical programming language, &lt;a href="http://www.streambase.com/developers/docs/latest/concepts/canvas.html"&gt;StreamBase StreamSQL EventFlow&lt;/a&gt;, it seemed like the place to be. My plan had been to pick up some contacts in the graphical languages space, and learn about what has come before. However, the participants (with one vocal exception) had already accepted as a given that UML would eventually decline in popularity, to be replaced by a and they were focused on what would come next.&lt;/p&gt;</description></item><item><title>VLDB Keynote: Data Access Patterns in The Amazon.com Technology Platform</title><link>https://bulrushlabs.com/articles/2007/09/25/vldb-keynote-data-access-patterns-in-the-amazoncom-technology-platform/</link><pubDate>Tue, 25 Sep 2007 06:53:00 +0000</pubDate><guid>https://bulrushlabs.com/articles/2007/09/25/vldb-keynote-data-access-patterns-in-the-amazoncom-technology-platform/</guid><description>&lt;p&gt;The opening keynote for &lt;a href="http://www.vldb2007.org/"&gt;this year’s VLDB&lt;/a&gt; was a great presentation by &lt;a href="http://www.vldb2007.org/program/keynotes.html#vogels"&gt;Amazon CTO Werner Vogels&lt;/a&gt;, describing their data management challenges. I particularly appreciated it because it echoed something I’ve been saying for a few years now: Web-scale companies have problems which cannot be managed with standard RDBMS, or with any common research systems, and so they have started to route-around the database research community.&lt;/p&gt;&#10;&lt;p&gt;Vogels presented lots of information. A big part was about the operational realities of a site as large as Amazon. This has been said before, but saying it to a room full of database researchers was a good thing:&lt;/p&gt;</description></item><item><title>Transactional Memory Not Solution To All Problems</title><link>https://bulrushlabs.com/articles/2006/12/01/transactional-memory-not-solution-to-all-problems/</link><pubDate>Fri, 01 Dec 2006 20:10:00 +0000</pubDate><guid>https://bulrushlabs.com/articles/2006/12/01/transactional-memory-not-solution-to-all-problems/</guid><description>&lt;p&gt;I was at MIT today and so I ended up going to an invited talk on computer architecture, &lt;a href="https://www.csail.mit.edu/events/eventcalendar/calendar.php?show=event&amp;amp;id=1298"&gt;Subtle Semantics and Unrestricted Implementation of Transactional Memory&lt;/a&gt;. &lt;a href="https://en.wikipedia.org/wiki/Transactional_memory"&gt;Transactional Memory&lt;/a&gt; is a very hot topic in systems and architecture. It is perceived to be a better model for programmers, so language designers like it. And there are a variety of options for pure-software and hardware-assisted implementations. And because it enables optimistic concurrency control, transactional memory can help make programs faster and more scalable on new multi-core architectures. There is every reason to believe that processor vendors will begin including some form of hardware support for transactional memory.&lt;/p&gt;</description></item></channel></rss>