Search This Blog

Tuesday, June 28, 2011

While looking for a MySQL RRD storage engine, I came across Round-Robin Database Storage Engine (RRD) (pdf) which describes how to setup a MySQL table to act as a RRD. The PDF appears to have been created in February of 2007 but the benchmark result at the end of 600 inserts/second says this was achieved on a 1350 MHz AMD CPU which suggests the article may be older.
I replicated the configuration and tested it on my laptop (5400 RPM disk, 2.4 GHz Intel T7700 CPU). With the MyISAM database, a brieft test of about 50k inserts resulted in ~7000 inserts/second. But the 25m max rows means the trigger functionality (the part that makes the table behave like an RRD) wasn’t really tested.
And the Original Pdf document can be downloaded from here

Infobright - The Database for Analytics

Infobright combines a columnar database with our Knowledge Grid architecture to deliver a self-managing, self-tuning database optimized for analytics. Infobright eliminates the need to create indexes, partition data, or do any manual tuning to achieve fast response for queries and reports. 


Thursday, June 23, 2011

HTTP 302 - Explained

The 302 redirection is described in RFC2616: “The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests“.
For example, using a 302 redirection from to, means that, although the page is temporarily redirected to the special action promotional page, the preferred address to be used in the future remains redirects should be used for temporary redirections.
Browsers automatically follow these redirections. They also display the temporary address in the address bar.
The same address pointed to by the redirection will eventually be saved in the browser favorites. Although this is not what should be done according to RFC2616, it does not seem to create many problems in the real world.
Related Articles

Monday, June 20, 2011

Facebook Connect

Here is a complete guide to integrating facebook (login, register, share, like, analytics) with your Websites.

Read Details @

Mysql - InnoDB - File Per Table

The data files that you define in the configuration file form the InnoDBsystem tablespace. The files are logically concatenated to form the tablespace. There is no striping in use. Currently, you cannot define where within the tablespace your tables are allocated. However, in a newly created tablespace, InnoDB allocates space starting from the first data file.
To avoid the issues that come with storing all tables and indexes inside the system tablespace, you can turn on the innodb_file_per_tableconfiguration option, which stores each newly created table in a separate tablespace file (with extension .ibd). For tables stored this way, there is less fragmentation within the disk file, and when the table is truncated, the space is returned to the operating system rather than still being reserved by InnoDB within the system tablespace.

MySQL: the Pros and Cons of InnoDB Tables

Unlike the majority of database systems, MySQL offers a number of table types. Choosing the correct type can be critical for your web application, but few developers realise the implications until it is too late.

MyISAM - Advantages

  1. Simplicity
  2. Speed
  3. Full-text searching
MyISAM - Dis-Advantages
  1. Poor data integrity
  2. Poor crash recovery
  3. Table locking

Should you use MyISAM?

MyISAM is an ideal choice if you are new to MySQL, your web application is simple, has to be fast, or use full-text searches. However, it should not be used when data integrity is a priority. Possible applications could include content management systems, online bookmarking tools, RSS readers, or simple search engines.
InnoDB Advantages
  1. Data integrity and foreign key constraints
  2. Transactions
  3. Row-level locking
InnoDB Dis-Advantages
  1. Increased complexity
  2. No full-text search
  3. Slower performance

Should you use InnoDB?

InnoDB is the best option if you need to create a reliable data-driven web application. In many ways, InnoDB is a better default choice than MyISAM:
  1. unless you have a significantly large or heavily-used system, the speed differences are likely to be negligible
  2. full-text searches can be implemented in other ways, e.g. more complex SQL or server-side search algorithms.
InnoDB is certainly the best choice for online shops, financial applications or any project where data integrity is essential. Defining tables is more complex, but your application will be more robust and may require less server-side code.
Note that you can mix table types within the same database. In practice, it may cause less developer confusion if you stick with a single table type.
READ COMPLETE ARTICLE @ :: Part 1 & Part 2

    Friday, June 10, 2011

    HTTP/1.1 100 CONTINUE - While POSTing data to web server using curl

    I have being trying to build a wrapper code to upload my applications/games on a famous appstore

    One problem which consume a lot of my bandwidth & worth mentioning is the "HTTP/1.1 100 CONTINUE" response headers from the web server while i was posting some variables & uploading files simultaneously.

    After much searching I found an excellent blog on the issue, click Here to read the detailed blog.

    Analyzing the TCP packets tell you that curl has set the HTTP Expect header as "Expect: 100-continue"

    Removing the Expect header allowed curl to send an HTTP 1.1 POST, with its payload, before the server generated HTTP 1.0 302 FOUND.  The fact that the server responded with 302 FOUND means the entire POST data was ignored on the server side, but the client DID send it!  In other words, we just wasted some bandwidth, and we are going to need to POST the data at least one more time.  When curl was expecting an HTTP 1.1 100 CONTINUE instead, it never sends the rest of the payload, and curl never complains, not even with -v.

    What is the takeaway message from all of this?  If you’re using curl to test your REST interface, then make sure you are aware of the behavior HTTP 1.1 100 CONTINUE.  You might notice it because your server receives a blank POST payload.  Your HTML forms will appear to have not been filled in, even though you specified one or more -F arguments on the curl command line.

    The solution for the versions of curl I’ve tested is to either remove the Expect header, or to tell curl to use HTTP 1.0 (since curl will default to 1.1 otherwise).  Once again, here are those examples:

    curl -H "Expect:" -F name=somevalue
    curl -0 -F name=somevalue
    This forces curl to POST the payload without waiting for the 100 CONTINUE response, and it is suitable for servers that don’t know how to provide a 100 CONTINUE.  I hope this helps someone out there to avoid the trouble I had debugging my wrapper interface.

    Search Options in Solr

    Although Lucene provides the ability to create your own queries through its API, it also provides a rich query language through the Query Parser, a lexer which interprets a string into a Lucene Query using JavaCC.
    Generally, the query parser syntax may change from release to release. This page describes the syntax as of the current release. If you are using a different version of Lucene, please consult the copy of docs/queryparsersyntax.html that was distributed with the version you are using.

    Wildcard Searches

    ? & * are supported in search except condition where they appear as the first character in the search

    Fuzzy Searches

    Lucene supports fuzzy searches based on the Levenshtein Distance, or Edit Distance algorithm. To do a fuzzy search use the tilde, "~", symbol at the end of a Single word Term. For example to search for a term similar in spelling to "roam" use the fuzzy search:
    This search will find terms like foam and roams.

    For complete help on Search options in Solr, visit here