• Roadhead (unregistered)

    This thing does indeed fly, I've never gotten data in and out of anything so quickly. This is manna from Heaven!

  • Steve The Cynic (unregistered)

    AP, yer a sick pup, no doubt about it.

    Although a quick look at the calendar suggests you aren't quite as serious as all that, in which case,...

    Yer a sick pup, no doubt about it. <-- This time for giving people ideas...

  • JayT (unregistered)

    Using javascript to access a database directly...

    Yep I can't see a single flaw in tha... oh wait... in superfast days is security still important? no? great news :D

    Nice contribution to the calendar date :D

  • (cs)

    Ha!!!!!

    It's my first one of the day. Thanks Alex.

  • Brompot (unregistered)

    APril fools DataBase!

  • Gullible (unregistered)

    ... for a few paragraphs at least :-D

  • SR (unregistered)

    I'm truly in awe of this development. I'll spend the rest of the day researching. I've booked a meeting to propose APDB as our production database from next week.

    There are times when it's worth being on the bleeding edge! What a great date to be alive! :oD

  • smit (unregistered)

    well played, sir

  • sadwings (unregistered)

    Nice of you to let TopCod3r submit today's article!

  • Anon (unregistered)

    Sweet; I just hacked this in to replace the aging MySQL box we had running as our development box, and we've noticed over a 300% increase in database I/O in our profiling tests. You just saved my team 3 months of optimisation work. Cheers!

  • (cs)

    I'm waiting for the first hackles-raised DBA to fire off a mega-flame without reading any comments or consulting the calendar. It should be hilarious.

  • fool (unregistered)

    I was getting angry/befuddled before I bailed mid-article, skipped ahead to the comments and realized I'd been punked. If I had continued reading to the part where it discussed bypassing HHD drivers I probably would have figured it out on my own. Probably. Anyway, nicely done.

  • AP != Attack Power? (unregistered) in reply to JayT
    JayT:
    Using javascript to access a database directly...

    Yep I can't see a single flaw in tha... oh wait... in superfast days is security still important? no? great news :D

    Nice contribution to the calendar date :D

    Of course security is important. And this is AWESOME SECURE, because the DB is SOOO FAST that the bad guys CAN'T KEEP UP! And also the mandatory ALL CAPS YELLING scares them away!

  • Sam (unregistered)

    This is awesome! Can you run a filesystem on top of it? Think about all the time that we could save if the filesystem were run from a database?

    Can you add XPath support as the next feature?

  • fool (unregistered) in reply to fool
    fool:
    I was getting angry/befuddled before I bailed mid-article, skipped ahead to the comments and realized I'd been punked. If I had continued reading to the part where it discussed bypassing HHD drivers I probably would have figured it out on my own. Probably. Anyway, nicely done.

    HDD.

    Shut up.

  • Jeff (unregistered)

    Really quite clever. I mean, the file system is a database, after all. I, too, wonder how many you're going to catch.

  • SR (unregistered) in reply to frits
    frits:
    I'm waiting for the first hackles-raised DBA to fire off a mega-flame without reading any comments or consulting the calendar. It should be hilarious.

    It's true that APDB does run better spread over 10 partitions.

    Outer sectors of the drives, people. Outer sectors only!

  • Jeff (unregistered) in reply to Jeff

    Replying to myself? Oi!

    Would have been even funnier if you'd talked about using LBA as a security feature.

  • fool (unregistered) in reply to SR
    SR:
    Outer sectors of the drives, people. Outer sectors only!

    Gah, I know what this is a reference to. Time to register here, I guess.

  • Virtualizer (unregistered)

    You too can now virtualize the World's Fastest Database. Run it on any OS, with any hard drive. Leverage the World's Fastest Database into your system too, with no pain, no need to write machine code, no need even to know about machine code.

  • Tom (unregistered)

    Will this be open sourced, or are you part of the evil monopoly?

  • JayT (unregistered) in reply to AP != Attack Power?

    ZOMG I hadn't thought of it that way!!! Using speed to avoid attacks, This database is the RoadRunner of the IT world!!!

  • ICH (unregistered)

    This method was used in the late 1970's early 1980's to get fast lookups on large mainframe database systems. The UK Police National Computer used this method for accessing the vehicle registration number (VRM) database. As the VRM was of a fixed and known format, 3 letters 3 digits and a final letter indicating year of registration,(unlike US registration numbers) It was possible to use this method. The VRM was its own hash key to the database. As the request came down the comms line, you could perform the lookup character by character without waiting to receive the full VRM, using Controller, string, drive unit, platter, track and sector. The down side is that you have to have space for all possible instances of data, not just those that have actually been used.

    And you thought it was a joke!

  • (cs)

    Damn i even got this up and running using WINE and it is still damn fast! When can we expect slave support?

  • P.M.Lawrence (unregistered)

    In the early days that was the approach Forth used for disk access whenever it was implemented on bare bones hardware without the help of any operating system, compilers for other languages or other software tools (usually because there wasn't any yet, which was what made Forth a good choice under the circumstances). Of course, the point of doing that was usually to provide enough of a toolkit to get other stuff up - like an operating system, compilers for other languages and other software tools.

  • (cs)

    Back in late 1985 I wrote an industrial control system where I needed to persist data to/from a local drive. The trouble was that the system could only be written in TI basic (not MS even though other parts of the system implemented MS Basic) and the drives were 8" floppies. And the only method I had to load/store data was a command that read and wrote individual sectors. So for the system to work my code read a sector of data and overlaid it on the top of an array of numbers. I then pulled the desired entries out of the array for use in the actual program.

    And to top it all off this was done asynchronously so that other parts of my code could respond to operator key presses in real-ish time.

    So in effect in 1985 I implemented APDB in a multitasking system written in TI Basic with an 8" floppy disk back-end storage system. But it all worked really well and that is one system that I am proud to have written as I managed to get the required functionality from a horrendous architecture.

  • BentFranklin (unregistered)

    Your database technology is FAT!

  • MicroChannel Man (unregistered)

    Arrgghh .... I can’t get this to work with my MicroChannel system. Any chance on supporting this in the next version?

  • All your base are belong to us (unregistered)

    I see some fundamental problems with this and look forward to seeing them released in the next update (which I suspect will take just about exactly a year to develop.)

    What happens with 4K sector disks that are coming on line. Will this still work?

    What if I want to run this on a flash drive? They don't address memory the same way.

    And can I hook up a hard drive to my smart phone so I can store and index my photos faster. I don't mind the extra weight.

    captcha: aliquam - Not quite as deep as an aquarium.

  • (cs)

    Ladies and gentlemen, I think we've found a GREAT product for SpectateSwamp's showdown!

  • you crazy (unregistered)

    Anyone run the attached exe? Even in a VM I wouldn't run a downloaded exe as an administrator.

  • Nibh (unregistered) in reply to All your base are belong to us
    All your base are belong to us:
    I see some fundamental problems with this and look forward to seeing them released in the next update (which I suspect will take just about exactly a year to develop.)

    What happens with 4K sector disks that are coming on line. Will this still work?

    What if I want to run this on a flash drive? They don't address memory the same way.

    And can I hook up a hard drive to my smart phone so I can store and index my photos faster. I don't mind the extra weight.

    I'm sure all this will be addressed in the enterprise edition, though I don't know if your cell phone will have enough memory to handle all the features.

  • Bryan The K (unregistered)

    I love a good April Fools joke.

  • Loof Lirpa (unregistered)

    Hmm, I think this is pretty dumb. You are taking away a lot of the abstraction which has been put in, over the years, for a very good reason. I can imagine that using physical locators is fast, but you are taking away a lot of the checks & strategy which the filesystem does for you.

    Admittedly this will make things faster in a single instance, but overall you will have worst robustness and you will have to implement filing strategies yourself (of course, this may be what you want!).

    Also, I am not sure how many people will want to give up SQL!

  • My Name Is Missing (unregistered)

    Cnngratulations, you've reinvented the original SABRE reservation system.

  • (cs)

    I was totally sold on the concept until he started going on about machine code.

    But I still think Alex might be on to something here.

  • KirbyG (unregistered)

    Any description of a release that includes "There are no known bugs" is a prank in itself...

  • Helix (unregistered) in reply to RHuckster

    This is common on an embedded system with low memory.

  • (cs) in reply to KirbyG
    KirbyG:
    Any description of a release that includes "There are no known bugs" is a prank in itself...
    Well if you don't test it you can honestly say there are no known bugs. I don't mind known bugs .. its the unknown ones that I object to.
  • Abe (unregistered)

    ROFL, from relational db via mmmm javascript down to hacking hdd microcontrollers , ROFL.

  • (cs)

    That's nice, but totally useless until there's a Brainfuck API.

  • (cs)
    There are no known bugs
    I knew this was a joke!
  • Anonymous (unregistered)

    Great job Alex, I spent the whole article wondering why you'd want to troll us like this but dammit if it isn't offically "Troll Day" today. Cheers, good laugh.

  • Anonymous (unregistered) in reply to you crazy
    you crazy:
    Anyone run the attached exe? Even in a VM I wouldn't run a downloaded exe as an administrator.
    Never used a disassembler before? Or a hex editor? Executables are not black boxes you know. If you want to know what it does just crack it open.
  • (cs) in reply to Anonymous

    Yeah, Wikipedia lists many available x86 disassemblers. Just pick one and give it a whirl!

    P.S. To Alex: Nice one, all the way! :)

  • DeepThought (unregistered)
    Alex Papadimoulis:
    Plus, they’re built to work hand-in-hand with the single-most fundamentally game-changing technology ever: JavaScript.

    I almost spit up coffee when I read this. Thanks for the laughs Alex!

  • Steve Syfuhs (unregistered)

    Assembly.Load(new byte[] {...});

    Nice.

  • (cs) in reply to Steve Syfuhs
    Steve Syfuhs:
    Assembly.Load(new byte[] {...});

    Nice.

    Could have at least run it through GZipStream. Otherwise a hex editor reveals too much. :P

  • cognitive delay (unregistered) in reply to you crazy
    you crazy:
    Anyone run the attached exe? Even in a VM I wouldn't run a downloaded exe as an administrator.

    this is what I did, it won't let you partition a virtual drive in a VM though... looks like you need a physical drive to use this thing.

  • iToad (unregistered)

    This really speeded up my latest project. However, if you want true performance, you should also scrap all of your Java code and rewrite it in X86 assembler.

Leave a comment on “Announcing APDB: The World's Fastest Database”

Log In or post as a guest

Replying to comment #304303:

« Return to Article